Hello alltogether, I'm new to the list, so please excuse any violations of listiquette... I didn't have to much to do with linux based firewalling and routing for quite a time and found that proxy-arp changed in between... As I struggled with it I found that the Advanced routing... howto wasn't to helpfull. Especially the documentation seems to be rather vice versa to what I found out using a 2.4.17 kernel. This is why I'm writing this mail to the list... What I wanted the machine to do was to answer with it's own MAC address on the external Interface if a certain different IP on the network was ARPrequested. The machine didn't need to route this address because it was natted. Cited from the howto (chap 13): ---8<---8<---8< /proc/sys/net/ipv4/conf/DEV/proxy_arp If you set this to 1, all other interfaces will respond to arp queries destined for addresses on this interface. Can be very useful when building 'ip pseudo bridges'. Do take care that your netmasks are very correct before enabling this! ---8<---8<---8< I interpret this in a way that if I enable this proxy_arp setting on (example) eth0 the machine will answer arp requests for the IPs in the network bound to eth0 on all other interfaces. What I found out was different (and makes significantly more sense to me): If I enable proxy_arp on an interface, _this_ interface answers with proxy-ARPs for all the IP addresses that are in it's local network, that are routed to other interfaces. Example: ---8<---8<---8<- ifconfig eth0 192.168.1.1 netmask 255.255.255.0 ifconfig eth1 172.16.1.1 netmask 255.255.0.0 echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp route add -host 192.168.1.2 gw 172.16.1.2 Then this machine answers ARP requests on eth0 for 192.168.1.2 and 192.168.1.1. (And by the way not for any addresses in the 172.16 network on eth0 and also not for any addresses in the 192.168.1.0 network on eth1). ---8<---8<---8<--- Maybe I do only get something wrong but in my opinion this is rather the opposite to what's explained in the howto... Still another thing I found out is that ip_forward needs to be turned on for this to work. Any comments? Open questions from my side are: - Why did they change the old behaviour? Ok, a pro for this behaviour is that it does figure out the right (tm) mac address on it's own so changing the NIC doesn't result in strange behaviour. But this also worked before with "arp -Ds 192.168.1.2 eth0 pub". - How do I proxy ARP for _another_ MAC address? Imagine a veryvery stupid device in the network that can't do ARP itself although it has a MAC address and should receive IP packets. I know of at least one device that's produced today that's that stupid. So there needs to be someone in the network that answers ARPs as a proxy for this device with the MAC for the device. I found no solution to configure this with Linux. Anyhow this new behaviour seems to be not overly the "unixway" to do things... (ok I'm a traditionalist and that's no reason not to change things). Enough whining. Thanks for the patience Stefan
