Hi Martin, Thanks for your hint. I downloaded the patch this weekend but didn't apply it. Because of a lack of time I compiled the kerned today. Patching was out of my mind. Anyway. Additionally installing the libdb3-dev package, everything works fine with the compelation of patched iproute2 package. Recompiled the kernel. (with the arprule-patch no change in the config, right?) Ok, the new kernel works fine, and so does the patched iproute2. Now to solve my arp problem ... To prevent eth0 (192.168.10.9) from answering arp-requests to 192.168.10.8 on eth1 and vice versa, I added the following rules: hamburg:~# ip arp add iif eth0 to 192.168.10.8 deny hamburg:~# ip arp add iif eth1 to 192.168.10.9 deny The result is getting no reply for an arping to 192.168.10.8, but to 192.168.10.9 with the proper answer: moskau:~ # arping -c 3 192.168.10.9 ARPING 192.168.10.9 from 192.168.10.1 eth0 Unicast reply from 192.168.10.9 [00:E0:7D:E2:9E:8D] 0.671ms Unicast reply from 192.168.10.9 [00:E0:7D:E2:9E:8D] 0.646ms Unicast reply from 192.168.10.9 [00:E0:7D:E2:9E:8D] 0.660ms Sent 3 probes (1 broadcast(s)) Received 3 response(s) hamburg:~# tcpdump -i eth0 | grep arp 20:44:05.344206 arp who-has 192.168.10.9 (Broadcast) tell moskau 20:44:05.344248 arp reply 192.168.10.9 is-at 0:e0:7d:e2:9e:8d 20:44:06.338178 arp who-has 192.168.10.9 (0:e0:7d:e2:9e:8d) tell moskau 20:44:06.338211 arp reply 192.168.10.9 is-at 0:e0:7d:e2:9e:8d 20:44:07.338334 arp who-has 192.168.10.9 (0:e0:7d:e2:9e:8d) tell moskau 20:44:07.338366 arp reply 192.168.10.9 is-at 0:e0:7d:e2:9e:8d hamburg:~# tcpdump -i eth1 | grep arp 20:44:05.344214 arp who-has 192.168.10.9 (Broadcast) tell moskau moskau:~ # arping -c 3 192.168.10.8 ARPING 192.168.10.8 from 192.168.10.1 eth0 Sent 3 probes (3 broadcast(s)) Received 0 response(s) hamburg:~# tcpdump -i eth0 | grep arp 20:44:16.168356 arp who-has 192.168.10.8 (Broadcast) tell moskau 20:44:17.220001 arp who-has 192.168.10.8 (Broadcast) tell moskau 20:44:18.220148 arp who-has 192.168.10.8 (Broadcast) tell moskau hamburg:~# tcpdump -i eth1 | grep arp 20:44:16.168365 arp who-has 192.168.10.8 (Broadcast) tell moskau 20:44:17.220009 arp who-has 192.168.10.8 (Broadcast) tell moskau 20:44:18.220155 arp who-has 192.168.10.8 (Broadcast) tell moskau On the gateway (hamburg) there was nothing announced in the kernlog. The arp-requests reach eth1 slightly later than eth0 but that souldn't influence the reply? Based on Martins little story about an inbound ARP requset, mayby my routing is faulty: > - it responds with the link layer address of the interface > through which it would route IP packets to this requestor So here is my routing (again): hamburg:~# ip route 62.x.x.89 dev eth2 scope link 62.x.x.88/29 dev eth3 scope link 192.168.11.0/24 dev eth4 proto kernel scope link src 192.168.11.8 192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.9 192.168.10.0/24 dev eth1 proto kernel scope link src 192.168.10.8 default via 62.x.x.89 dev eth2 The values of arp_filter and rp_filter are set to 1 for 'all', 'eth0' and 'eth1' I've got no further ideas right now. Does anybody? Thanks, oli PS: To answer sabats question why not using two boxes. The main advantage I see in combining both gateways in one box is to keep the dmz with routable IPs accessible for both gateways. Installing another box would force me to loose another IP from my dmz-range. Applying firewall rules to only one box seems to be another advantage. ... And now I hope that I'm that near having solved this problem with great help from you guys .. I dont want to give up.
