From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Brian J. Murrell" Date: Fri, 26 Nov 2004 14:39:56 +0000 Subject: Re: [LARTC] simple dual Internet connection setup not sending Message-Id: <1101479996.8287.113.camel@pc> MIME-Version: 1 Content-Type: multipart/mixed; boundary="=-5YMeInMLIuKW8q6vJV2X" List-Id: References: <1101398346.8287.66.camel@pc> In-Reply-To: <1101398346.8287.66.camel@pc> To: lartc@vger.kernel.org --=-5YMeInMLIuKW8q6vJV2X Content-Type: text/plain Content-Transfer-Encoding: quoted-printable To followup on my own posting, with more information... On Thu, 2004-11-25 at 10:59 -0500, Brian J. Murrell wrote: > I have a very simple setup exactly as described in the HOWTO section " > 4.2. Routing for multiple uplinks/providers". >=20 > One is cable (eth1: dhcp) and the other is PPPoE (ppp0). These are both on the same physical interface, eth1. IOW, the PPPoE packets are sent to the PPPoE "modem" on eth1. eth1 is also plugged into the cable provider's "modem" as such: +---------- Cable Modem +--------+ | | | +--+--+ | GW eth1 ------| HUB | | | +--+--+ +--------+ | +---------- PPPoE Modem This set up works, physically. I can tcpdump on eth1 and see both regular ethernet traffic going to an from my cable provider, as well as PPPoE encapsulated traffic coming in through my PPPoE connection: 09:29:58.109041 00:08:e2:33:f8:54 > 00:a0:24:2a:1f:72, ethertype IPv4 (0x08= 00), length 130: IP 66.96.26.190.922 > 24.235.240.15.52814: P 49:113(64) ac= k 48 win 28800 09:29:58.109344 00:a0:24:2a:1f:72 > 00:08:e2:33:f8:54, ethertype IPv4 (0x08= 00), length 66: IP 24.235.240.15.52814 > 66.96.26.190.922: . ack 113 win 32= 740 09:29:58.117164 00:90:1a:40:43:d7 > 00:a0:24:2a:1f:72, ethertype PPPoE S (0= x8864), length 82: PPPoE [ses 0x1473] PPP-IP (0x0021), length 62: IP 66.96= .26.190.52797 > 66.11.173.224.25: S 3517919246:3517919246(0) win 5840 09:29:58.118789 00:a0:24:2a:1f:72 > 00:08:e2:33:f8:54, ethertype IPv4 (0x08= 00), length 74: IP 66.11.173.224.25 > 66.96.26.190.52797: S 3862223559:3862= 223559(0) ack 3517919247 win 5792 As you can see, packets 1 and 2 are an established TCP session over the cable connection and packet 3 is an incoming PPPoE encapsulated packet coming in on the PPPoE connection and interestingly enough, packet 4 is an erroneously transmitted packet demonstrating exactly my problem. It is the response to packet 3. As you can see it has all of the correct IP and TCP headers, it is just sent physically via eth1 and not ppp0. =20 Heh. Indeed if my cable provider were not filtering packets from me that don't have my assigned source address, this would all work. Just a reminder of my iptables SNAT rules for context of my point below... > My iptables "nat" setup looks like this: >=20 > Chain POSTROUTING (policy ACCEPT 364 packets, 26735 bytes) > pkts bytes target prot opt in out source desti= nation > 258 19801 eth1_masq all -- * eth1 0.0.0.0/0 0.0.0= .0/0 > 0 0 ppp0_masq all -- * ppp0 0.0.0.0/0 0.0.0= .0/0 >=20 > Chain eth1_masq (1 references) > pkts bytes target prot opt in out source desti= nation > 252 19021 SNAT all -- * * 10.75.22.0/24 0.0.0= .0/0 to:24.235.240.15 > 0 0 SNAT all -- * * 192.168.66.0/24 0.0.0= .0/0 to:24.235.240.15 >=20 > Chain ppp0_masq (1 references) > pkts bytes target prot opt in out source desti= nation > 0 0 SNAT all -- * * 10.75.22.0/24 0.0.0= .0/0 to:66.11.173.224 > 0 0 SNAT all -- * * 192.168.66.0/24 0.0.0= .0/0 to:66.11.173.224 > Is this a problem in that iproute2 selects the default route before > SNATting is done to change the source address of the packet, which does > not happen of course until POSTROUTING? The answer to this is of course no. Because the source address of the erroneously-sent-via-eth1 packet (#4 in the above trace) has been correctly re-written (NATted) to 66.11.173.224, then according to the SNAT rules above, the packet is being sent through the correct interface (ppp0). What still remains inconsistent however is that according to the rules above and currently on my gateway, the "ppp0_masq" rules show 0 hits. How can the source address be correctly re-written to 66.11.173.224 and the rule that does the re-writing show 0 hits? There is definitely something fishy going on here. b. --=-5YMeInMLIuKW8q6vJV2X Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBp0A8l3EQlGLyuXARAgT0AKCUltbfyx4+mEH5d/2XHxa6ZyCWOwCgpmC+ SivHWicOgCnrDebqLMUwFx4= =6IlW -----END PGP SIGNATURE----- --=-5YMeInMLIuKW8q6vJV2X-- _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/