Re: Re: [LARTC] Double gateway - Two interfaces to same subnet

Re: Re: [LARTC] Double gateway - Two interfaces to same subnet

[lartc]

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.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: Re: [LARTC] Double gateway - Two interfaces to same subnet

[Martin A. Brown]

Short reply--gotta run,

Don't forget that the "ip arp" utility works in conjunction with the other
ARP management features of the kernel, so you do not want to use
arp_filter while using "ip arp" (in this case).

Snipped from iparp.txt:

  The ARP filtering rules are considered only when the ARP code is
  ready  to reply to remote ARP request or to send ARP request. As result,
  the  default action  for tables "input"  and "forward"  depends on other
  things   such  as   device  flags   (rp_filter,  arp_filter,  medium_id,
  proxy_arp) and the routing rules. If the default action is to ignore the
  remote  ARP request the ARP rules are not analyzed. For table output the
  default action is always allow.

Good luck,

-Martin

-- 
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/