Date: Fri, 15 Jun 2007 21:34:25 -0700 From: Christopher Cowart <ccowart@rescomp.berkeley.edu> To: Julian Elischer <julian@elischer.org> Cc: freebsd-net@freebsd.org, sysadmin@rescomp.berkeley.edu Subject: Re: Routing outbound IP packets on multihomed box Message-ID: <20070616043425.GH2335@rescomp.berkeley.edu> In-Reply-To: <46733055.4080502@elischer.org> References: <20070615213454.GE2335@rescomp.berkeley.edu> <467312FF.5020506@acm.poly.edu> <20070615231255.GG2335@rescomp.berkeley.edu> <46733055.4080502@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--/9ZOS6odDaRI+0hI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 15, 2007 at 05:35:33PM -0700, Julian Elischer wrote: > 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: 169.229.79.139/25 > >>>vlan526: 169.229.126.9/24 > >>> > >>>The default gateway is 169.229.79.129. The router for the 126 subnet is > >>>169.229.126.1.=20 > >>> > >>>netstat -rn: > >>>| Destination Gateway Flags Refs Use Netif= =20 > >>>Expire > >>>| default 169.229.79.129 UGS 0 102537 em0 > >>>| 127.0.0.1 127.0.0.1 UH 0 217 lo0 > >>>| 169.229.79.128/25 link#1 UC 0 0 em0 > >>>| 169.229.79.129 00:15:c7:b9:f4:80 UHLW 2 4 em0 = =20 > >>>1193 > >>>| 169.229.79.139 00:11:25:ab:42:70 UHLW 1 589 lo0 > >>>| 169.229.126/24 link#9 UC 0 0 vlan52 > >>>| 169.229.126.1 00:15:c7:b9:f4:80 UHLW 1 34 vlan52 = =20 > >>>1200 > >>>| 169.229.126.9 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.=20 > >>> > >>>The problem is I can't get 2-way connectivity with the IP address on > >>>vlan526. > >>> > >>>Using my workstation on a third subnet (169.229.127.38/24), I cannot > >>>ping 169.229.126.9. I leave the ping running and do some tcpdumps on= =20 > >>>the server. > >>> > >>>$ sudo tcpdump -ni vlan526 host 169.229.127.38 > >>>| 14:14:37.002920 IP 169.229.127.38 > 169.229.126.9: ICMP echo=20 > >>>| request, id 15733, seq 35, length 64 > >>>| 14:14:38.003037 IP 169.229.127.38 > 169.229.126.9: ICMP echo=20 > >>>| request, id 15733, seq 36, length 64 > >>> > >>>Notice there are no echo replies. That's because they're being sent=20 > >>>here: > >>> > >>>$ sudo tcpdump -ni em0 host 169.229.127.38 > >>>| 14:15:42.006997 IP 169.229.126.9 > 169.229.127.38: ICMP echo reply,= =20 > >>>| id 15733, seq 100, length 64 > >>>| 14:15:43.007118 IP 169.229.126.9 > 169.229.127.38: ICMP echo reply,= =20 > >>>| 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 > >>>169.229.126.9. The router (169.229.79.139) 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 t= he > >>>126 subnet. I tried the following ipfw rule right after allow loopback > >>>traffic (my second rule): > >>> > >>>fwd 169.229.126.1 ip from 169.229.126.9 to not 169.229.126.0/24 > >>> > >>>Still no luck. Has anyone set up a multihomed box on *different* subne= ts > >>>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= =20 > >>form, if that's an option for you: > >> > >>pass out route-to (vlan256 169.229.126.1) from 169.229.126.9 to any > >> > >>This tells PF to send all packets sent from 169.229.126.9 through the= =20 > >>vlan256 interface with a next-hop address of 169.229.126.1. > > > >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 opt= ion > (and it's not the couple of versions of the OS where you also needed the > IPFIREWALL_FORWARD_EXTENDED option as well.. I had forwarding enabled, but not the EXTENDED flag. Apparently bypassing the routing table in the firewall is an "unsafe" practice. Now I can source traffic from the vlan526 interface correctly. Thanks! > also, you need to make it an 'out' rule..i.e.=20 > fwd 169.229.126.1 ip from 169.229.126.9 to not 169.229.126.0/24 out This doesn't appear to be necessary... The next step, and here I'm having more problems, is I want to NAT traffic using the vlan526 interface. Using the same configuration as above, I've added: vlan80: 10.80.1.1/16 When a NAT'd client pings off the 126 subnet (say, 169.229.127.38),=20 the packets go out em0 again. My ipfw ruleset looks like this: allow all from any to any via lo0 divert natd ip from not me to any via 169.229.126.9 fwd 169.229.126.1 ip from 169.229.126.9 to not 169.229.126.0/24 allow icmp from any to any My understanding of divert is that after natd munges the packets, they'll return to the ipfw rules immediately following rule 13. In this case, traffic appearing from the NAT ip address should be forwarded to the 126 router on the next-hop. When I do `tcpdump -ni em0 host 169.229.127.38`, I notice the outbound ICMP echo requests have src-addr of 10.80.x.x (IP address of the nat'd client). Does this mean that as ipfw continues processing the packet, even after natd has munged it, that as far as ipfw is concerned, the src-addr of the packet hasn't changed? In other words, would I need to write a complicated set of rules that do something like: divert natd ip from not me to any via 169.229.126.9 fwd 169.229.126.1 ip from 169.229.126.9 to not 169.229.126.0/24 fwd 169.229.126.1 ip from 10.80.0.0/16 to not 169.229.126.0/24 Any recommendations on how to solve the NATing extension of this routing problem? Thanks again, --=20 Chris Cowart Lead Systems Administrator Network Infrastructure, RSSP-IT UC Berkeley --/9ZOS6odDaRI+0hI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFGc2hRV3SOqjnqPh0RAgufAJ97WylzqEY5HMvZ3la1p7s9+WTXLwCeJ1A1 Qp8mVkdI211eFHaPPFmy1YQ= =sDVU -----END PGP SIGNATURE----- --/9ZOS6odDaRI+0hI--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070616043425.GH2335>