Re: double packet

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Marco,

On Sun, 18 Dec 2005, Marco Berizzi wrote:

> Bill Fink wrote:
> 
> >On Sat, 17 Dec 2005, Marco Berizzi wrote:
> 
> > > Hello.
> > > I have a pretty strange problem with routing and iptables mark.
> > > My firewall has a classic 3 NIC config: one nic connected to the
> > > ISP routers, one network for DMZ and the third network for my
> > > private network. Here is the schema:
> > >
> > >
> > > 	       HUB
> > > HDSL router----+----ADSL router
> > > 		|
> > > 		|
> > >      HDSL IP---eth0---ADSL IP
> > > 		|
> > > 		|
> > > 	+-------+------+
> > > 	|	       |
> > > 	|	       |
> > > 	|	       |
> > > 	|	       |
> > > 	|	       +-----eth1---ADSL public network and HDSL public network
> > > 	|	       |
> > > 	|	       |
> > > 	|	       |
> > > 	|	       |
> > > 	+-------+------+
> > > 		|
> > > 		|
> > > 	       eth2---172.16.1.1
> > > 		|
> > > 		|
> > > 		+----Private network 172.16.0.0/23
> >
> >I believe it is doing exactly what you told it to do, although
> >obviously not what you wanted it to do.  :-)
> 
> ;-)
> 
> > > As you may see from the schema I have two internet connections:
> > > one hdsl and one adsl (for surfing the internet).
> > > This is the output from ip rule sh:
> > >
> > > 0:	from all lookup local
> > > 200:	from all fwmark 0x2 lookup test
> > > 32766:	from all lookup main
> > > 32767:	from all lookup default
> >
> >You are telling it to use routing table test for _ALL_ packets
> >marked with 2.
> 
> Yes.

OK.

> > > This is the relevant piece of my firewall:
> > >
> > > $IPTABLES -I FORWARD -s 172.16.1.15 --protocol icmp -j ACCEPT
> > > $IPTABLES -t nat -I POSTROUTING -s 172.16.1.15 --protocol icmp -j SNAT 
> >--to
> > > 'ADSL IP'
> > > $IPTABLES -t mangle -I PREROUTING -s 172.16.1.15 --protocol icmp -j MARK
> > > --set-mark 2
> >
> >You are marking all ICMP packets with a source of 172.16.1.15 with 2
> >(note it doesn't matter what the destination IP address is in this case).
> 
> Yes.

OK.

> > > This is the output from "ip route sh table main":
> > >
> > > 'HDSL router ip' dev eth0  scope link
> > > 'ADSL router ip' dev eth0  scope link
> > > 'ADSL public network' dev eth1  proto kernel  scope link  src 'ADSL IP'
> > > 'HDSL public network' dev eth1  proto kernel  scope link  src 'HDSL IP'
> > > 172.16.0.0/23 dev eth2  proto kernel  scope link  src 172.16.1.1
> > > 127.0.0.0/8 dev lo  scope link
> > > default via 'HDSL router ip' dev eth0  metric 1
> > >
> > > And this is the output from "ip route sh table test":
> > >
> > > default via 'ADSL router ip' dev eth0  metric 1
> > >
> > > So far, so good.
> >
> >Not really.  The only route in the test routing table is the default
> >route which matches _ALL_ packets.  The end result is that you have
> >marked all ICMP packets with a source of 172.16.1.15 with 2 (regardless
> >of the destination address), which then causes the test routing table
> >to be used, which finally matches the test default route and causes
> >all such packets to be routed out eth0 via the 'ADSL router ip',
> >which is exactly what you're seeing from the tcpdump output.
> 
> Ok, this is want I want to do.

This is where I become somewhat confused as to what you're trying
to accomplish.  You want packets from your private net to your DMZ
to be routed out to the Internet and back rather than directly out
to the DMZ???

> > > If I try to ping any host on the internet from the 172.16.1.15
> > > box, packet are natted to 'ADSL IP' and then they are routed
> > > through the ADSL router. But if I try to ping a system in the
> > > DMZ with ip an address belonging to the 'HDSL public network'
> > > I don't get any response. This is the tcpdump capture on the
> > > eth0 for a single ip echo request:
> > >
> > > 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).  You can
verify this by adding the "-vv" and "-e" parameters to tcpdump, which
will let you see if the TTL has been decremented, and examine the
Ethernet MAC addresses in the packets and compare them with the MAC
addresses of your Linux box, and ADSL and HDSL routers.

> >This is to be expected from the rules you defined.
> 
> Ok. Now it's clear for me why tcpdump logs two packet. Thanks for the
> explanation.
> 
> > > and this the tcpdump capture on the eth2:
> > >
> > > tcpdump -p -n -i eth2 host ip 'HDSL public network host'
> > > 17:39:12.999001 IP 172.16.1.15 > 'HDSL public network host': ICMP echo
> > > request, id 256, seq 6656, length 40
> > >
> > > On eth1 I don't see any packet.
> >
> >Because your test default route sent it out eth0.
> 
> 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.

> 8) why I don't see on eth0 the above packet?

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.

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.

It could also be as simple as you needing a FORWARD rule for your
ADSL IP address.

> Thanks for the reply Bill.

I hope this helps.

						-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

[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux 802.1Q VLAN]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Git]     [Bugtraq]     [Yosemite News and Information]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux PCI]     [Linux Admin]     [Samba]

  Powered by Linux