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".
>
> 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 (0x0800), length 130: IP 66.96.26.190.922 > 24.235.240.15.52814: P 49:113(64) ack 48 win 28800 <nop,nop,timestamp 59750486 1599607031>
09:29:58.109344 00:a0:24:2a:1f:72 > 00:08:e2:33:f8:54, ethertype IPv4 (0x0800), length 66: IP 24.235.240.15.52814 > 66.96.26.190.922: . ack 113 win 32740 <nop,nop,timestamp 1599607172 59750486>
09:29:58.117164 00:90:1a:40:43:d7 > 00:a0:24:2a:1f:72, ethertype PPPoE S (0x8864), 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 <mss 1400,sackOK,timestamp 59750486 0,nop,wscale 0>
09:29:58.118789 00:a0:24:2a:1f:72 > 00:08:e2:33:f8:54, ethertype IPv4 (0x0800), length 74: IP 66.11.173.224.25 > 66.96.26.190.52797: S 3862223559:3862223559(0) ack 3517919247 win 5792 <mss 1460,sackOK,timestamp 2207063156 59750486,nop,wscale 0>
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.
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:
>
> Chain POSTROUTING (policy ACCEPT 364 packets, 26735 bytes)
> pkts bytes target prot opt in out source destination
> 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
>
> Chain eth1_masq (1 references)
> pkts bytes target prot opt in out source destination
> 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
>
> Chain ppp0_masq (1 references)
> pkts bytes target prot opt in out source destination
> 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.
Attachment:
signature.asc
Description: This is a digitally signed message part
