Routing outbound IP packets on multihomed box
julian at elischer.org
Sat Jun 16 00:35:36 UTC 2007
Christopher Cowart wrote:
> On Fri, Jun 15, 2007 at 06:30:23PM -0400, Boris Kochergin wrote:
>> Christopher Cowart wrote:
>>> I have a server with two NICs:
>>> em0: 22.214.171.124/25
>>> vlan526: 126.96.36.199/24
>>> The default gateway is 188.8.131.52. The router for the 126 subnet is
>>> netstat -rn:
>>> | Destination Gateway Flags Refs Use Netif
>>> | default 184.108.40.206 UGS 0 102537 em0
>>> | 127.0.0.1 127.0.0.1 UH 0 217 lo0
>>> | 220.127.116.11/25 link#1 UC 0 0 em0
>>> | 18.104.22.168 00:15:c7:b9:f4:80 UHLW 2 4 em0
>>> | 22.214.171.124 00:11:25:ab:42:70 UHLW 1 589 lo0
>>> | 169.229.126/24 link#9 UC 0 0 vlan52
>>> | 126.96.36.199 00:15:c7:b9:f4:80 UHLW 1 34 vlan52
>>> | 188.8.131.52 00:18:f8:09:d3:a5 UHLW 1 8 lo0
>>> The IP address on em0 works exactly as one would expect. I have full IP
>>> connectivity to it from other subnets.
>>> The problem is I can't get 2-way connectivity with the IP address on
>>> Using my workstation on a third subnet (184.108.40.206/24), I cannot
>>> ping 220.127.116.11. I leave the ping running and do some tcpdumps on
>>> the server.
>>> $ sudo tcpdump -ni vlan526 host 18.104.22.168
>>> | 14:14:37.002920 IP 22.214.171.124 > 126.96.36.199: ICMP echo
>>> | request, id 15733, seq 35, length 64
>>> | 14:14:38.003037 IP 188.8.131.52 > 184.108.40.206: ICMP echo
>>> | request, id 15733, seq 36, length 64
>>> Notice there are no echo replies. That's because they're being sent
>>> $ sudo tcpdump -ni em0 host 220.127.116.11
>>> | 14:15:42.006997 IP 18.104.22.168 > 22.214.171.124: ICMP echo reply,
>>> | id 15733, seq 100, length 64
>>> | 14:15:43.007118 IP 126.96.36.199 > 188.8.131.52: ICMP echo reply,
>>> | id 15733, seq 101, length 64
>>> I repeated this last snoop with a -w and loaded it into ethereal. The
>>> echo replies being sent out on em0 indeed have a source address of
>>> 184.108.40.206. The router (220.127.116.11) drops these packets on the
>>> floor, because their source address isn't routable on that interface.
>>> Because routing is based on destination, not source address, I'm not
>>> sure how to get packets sourced from the 126 subnet to the router on the
>>> 126 subnet. I tried the following ipfw rule right after allow loopback
>>> traffic (my second rule):
>>> fwd 18.104.22.168 ip from 22.214.171.124 to not 126.96.36.199/24
>>> Still no luck. Has anyone set up a multihomed box on *different* subnets
>>> before without routing them through the FreeBSD box? Does anyone have
>>> any pointers or things I should be looking at?
>> Hi. I've come across this problem but solved it with a PF rule of this
>> form, if that's an option for you:
>> pass out route-to (vlan256 188.8.131.52) from 184.108.40.206 to any
>> This tells PF to send all packets sent from 220.127.116.11 through the
>> vlan256 interface with a next-hop address of 18.104.22.168.
> Unfortunately, I don't think we can use pf. The rest of our
> infrastructure is ipfw and we don't particularly want this to be a
> one-off. I was under the impression that my ipfw rule did exactly this,
> by sending the packets to the 126 router as their next hop.
> Anyone have any ideas on whether an ipfw fwd rule can be used in a
> similar way to this pf rule?
> Thanks again,
he ipfw rule should work, assuming you have the IPFIREWALL_FORWARDING option
(and it's not the couple of versions of the OS where you also needed the
IPFIREWALL_FORWARD_EXTENDED option as well..
also, you need to make it an 'out' rule..i.e.
fwd 22.214.171.124 ip from 126.96.36.199 to not 188.8.131.52/24 out
More information about the freebsd-net