Good morning Bill.
I think I have found the "feature": /proc/sys/net/ipv4/conf/*/log_martians
Enabling it and then dmesging I see:
Dec 20 10:18:42 Pleiadi kernel: martian source 'HDSL_public_network_host'
from 'ADSL_IP', on dev eth0
Dec 20 10:18:42 Pleiadi kernel: ll header:
00:60:97:d8:e5:01:00:07:50:7e:65:e0:08:00
So I think linux will drop these packets anyway (they will even not reach
netfilter I think):
may anyone confirm this?
Bill Fink wrote:
Marco,
On Mon, 19 Dec 2005, Marco Berizzi wrote:
> Bill Fink wrote:
>
> > > > > tcpdump -p -n -i eth0 host ip 'HDSL public network host'
> > > > > 17:39:12.999287 IP 'ADSL IP' > 'HDSL public network host': ICMP
echo
> > > > > request, id 256, seq 6656, length 40
> > > > > 17:39:13.037471 IP 'ADSL IP' > 'HDSL public network host': ICMP
echo
> > > > > request, id 256, seq 6656, length 40
> >
> >I didn't look at this tcpdump output closely enough before. Now that
> >I look at it again this does not appear to be a tcpdump artifact since
> >there is almost a 40 ms difference in the timestamps. Instead it
appears
> >as if the packet has been routed out to the Internet and back and is
now
> >being received on eth0 (presumably from your HDSL router).
>
> Yes: packet are goining out through the adsl router and they are coming
> back through the hdsl router :-))
> Also I'm getting the echo reply when I ping the "HDSL router ip" from
the
> 172.16.1.15 host :-)
That's good.
> >You can
> >verify this by adding the "-vv" and "-e" parameters to tcpdump, which
> >will let you see if the TTL has been decremented
>
> Yes, TTL are decremented and MAC addresses are looking fine.
Also good.
> > > Ok. Please correct me:
> > >
> > > 1) Packet start on 172.16.1.15 box. Destination IP is 'HDSL public
> >network
> > > host'
> > > 2) I'm snatting those icmp packets with 'ADSL IP'
> > > 3) I'm marking those packet with "mark 2"
> > > 4) I'm routing this packet through "ADSL router"
> > > 5) packet leaving eth0 has source ip='ADSL IP' and destination
ip='HDSL
> > > public network host'
> > > 6) the above packet should be sent to the internet by "ADSL router".
> >Right?
> >
> >Right.
> >
> > > 7) "HDSL router" should receive the above packet from the internet
and
> > > should send it
> > > to eth0. Right?
> >
> >Right.
>
> Ok, this is happening.
Yup.
> > > 8) why I don't see on eth0 the above packet?
>
> Wrong phrase: I see the the packet, tcpdump logs the packet with
> a smaller TTL.
>
> >I now think you are. The packet is probably just being dropped at
> >this point. Such a packet with a source IP address of your ADSL IP
> >coming in from the Internet destined for your HDSL public network
> >host would normally be considered a classic case of a spoofed
> >source IP address, and an excellent reason for discarding such
> >a packet by the kernel.
>
> Aha!
>
> >This is controlled by the rp_filter sysctl parameter, as documented
> >in the /usr/src/linux/Documentation/networking/ip-sysctl.txt file:
> >
> >rp_filter - BOOLEAN
> > 1 - do source validation by reversed path, as specified in
RFC1812
> > Recommended option for single homed hosts and stub network
> > routers. Could cause troubles for complicated (not loop
free)
> > networks running a slow unreliable protocol (sort of RIP),
> > or using static routes.
> >
> > 0 - No source validation.
> >
> > conf/all/rp_filter must also be set to TRUE to do source
> >validation
> > on the interface
> >
> > Default value is 0. Note that some distributions enable it
> > in startup scripts.
> >
> >So check your /proc/sys/net/ipv4/conf/*/rp_filter settings.
>
> Ok. I have checked this settings. My firewall set rp_filter to 1. I have
> set all rp_filter (lo, eth0, eth1, eth2, all, default) to 0, but nothing
> as changed: I don't see any packet on eth1
Bummer.
> Perhaps is there any other flag?
The only other flags I can think of are:
/proc/sys/net/ipv4/ip_forward
/proc/sys/net/ipv4/conf/*/forwarding
But I presume these are all set to 1.
Can you "ping -I ADSL_IP HDSL_public_network_host" (while monitoring
eth1 with tcpdump)? And check ARP tables.
> >It could also be as simple as you needing a FORWARD rule for your
> >ADSL IP address.
>
> I have also tried this:
>
> iptables -P FORWARD ACCEPT
>
> Anything else to try?
Since the packet is being received on eth0 by your Linux box, I can
only think of a few things that would prevent it from being forwarded
out eth1.
1. TTL expired (incoming TTL of 0 or 1).
2. No route entry, but you seem to have the correct routes
(but do doublecheck to make sure you don't have a typo
in your eth1 IP address or netmask).
3. No ARP entry, but I'm not sure what would cause this.
4. Explicit IP tables rule preventing forwarding or output
of packet (I'm not an iptables expert but I think the
"iptables -P FORWARD ACCEPT" only sets a default policy
if no explicit rule matches, but I'm not really sure
about that). And remember if you add an explicit rule
allowing the desired packets through, where it gets
added in the iptables rule chain is crucial, as the
order of the rules can be extremely important.
5. Some kernel feature or parameter I'm not aware of that's
trying to be helpful by avoiding source IP address spoofing
(or perhaps the firewall has an implicit rule for this),
or avoiding possible packet looping (you're essentially
trying to forward a packet out eth1 with a source IP
address on eth1 that wasn't locally sourced by the
Linux box itself which could possibly be construed
as evidence of a network loop).
6. Kernel bug (probably not likely).
> Thanks a lot for the feedback.
You're welcome. This is a tough one.
> PS: I have proxy_arp enabled on the eth0 device, but I think this
> should not be relevant for this issue.
Probably not, but it still might be worth turning off just in case.
The only way I can see it being a problem is if eth0 and eth1 were
both on the same physical infrastructure, and then the ARP request
for the HDSL public network host might get ARP replies both from
the real host and the Proxy ARP from eth0 on the Linux host, which
might confuse things.
-Bill
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
