Private traffic seen on public NATed interface - Linux 2.6.10-11
macleajb at ednet.ns.ca
Wed Mar 16 13:49:04 CET 2005
Francesco Ciocchetti wrote:
> James MacLean wrote:
>> There is a session properly NATed between the client and the server.
>> It just happens that some traffic in that session escapes from being
>> NATed on it's way from the client (private IP space) to the server.
>> How far it gets we do not know :).
> the problem is that some traffic can't excape from session :)
> I mean, the NAT table in netfilter is match only once per session. The
> first packet is SNATted or DNATted , then all sequent packets of the
> same connection does not touch the nat table , instead it is NATTED
> based on connection tables.
Understood. And please excuse my lack of technical knowledge about the
whole ip_conntrack experience :). We here are long time users and have
never seen this situation before. Especially on multiple boxes. So I
thought it was best to get the info out to this list in case there is
more to it then bad configuration on our part ;(. If it was only
occurring on one box, we'd kick it around more, but it appears to be a
little more pronounced ;).
> I have a 2.6.11 firewall , that was a 2.6.10 before, and i never had
> such an experience ... my packets never escaped from session table :)
Ok. But then explain how _any_ traffic can get through unNATed via a
table where all private IPs are SNATed according to the rules. This is
what we can not understand. Even adding an SNAT to the very top of the
POSTROUTING chain didn't help.
We only tripped over this by accident. Otherwise, we'd still not have
any clue that this was happening.
> I would try to flush iptables rules and try with just a few rules with
> NAT to check if it does work or not ... then insert your rules by step
> until you find where your problems lives.
Appreciate your thoughts. These sites are a bit to busy to probably do
it that way, but we'll see if we can get a controlled environment to
Some more dump, just for fun :)...
08:30:11.100766 IP 10.0.5.243.1270 > 184.108.40.206.http: F
3707121597:3707121597(0) ack 502138606 win 64970
08:30:17.054926 IP 220.127.116.11.36703 > 18.104.22.168.http: S
978075472:978075472(0) win 5840 <mss 1460,sackOK,timestamp 1145498148
08:30:17.136969 IP 22.214.171.124.http > 126.96.36.199.36703: S
1839730991:1839730991(0) ack 978075473 win 65535 <mss 1460,nop,wscale
1,nop,nop,timestamp 1702037157 1145498148>
08:30:17.136998 IP 188.8.131.52.36703 > 184.108.40.206.http: . ack 1 win
1460 <nop,nop,timestamp 1145498230 1702037157>
08:30:17.137710 IP 220.127.116.11.36703 > 18.104.22.168.http: P
1:552(551) ack 1 win 1460 <nop,nop,timestamp 1145498230 1702037157>
08:30:17.221654 IP 22.214.171.124.http > 126.96.36.199.36703: F
521:521(0) ack 552 win 33304 <nop,nop,timestamp 1702037165 1145498230>
08:30:17.221695 IP 188.8.131.52.36703 > 184.108.40.206.http: . ack 1 win
1460 <nop,nop,timestamp 1145498314 1702037157>
08:30:17.221777 IP 220.127.116.11.http > 18.104.22.168.36703: P
1:521(520) ack 552 win 33304 <nop,nop,timestamp 1702037165 1145498230>
08:30:17.221799 IP 22.214.171.124.36703 > 126.96.36.199.http: . ack 522
win 1728 <nop,nop,timestamp 1145498315 1702037165>
08:30:17.222489 IP 188.8.131.52.36703 > 184.108.40.206.http: F
552:552(0) ack 522 win 1728 <nop,nop,timestamp 1145498315 1702037165>
08:30:17.304268 IP 220.127.116.11.http > 18.104.22.168.36703: . ack 553
win 33304 <nop,nop,timestamp 1702037174 1145498315>
08:30:32.472154 IP 10.0.4.10.2107 > 22.214.171.124.http: F
3949942874:3949942874(0) ack 724796989 win 63967
08:30:34.730636 IP 10.0.4.10.2107 > 126.96.36.199.http: F 0:0(0) ack 1
08:30:39.345472 IP 10.0.4.10.2107 > 188.8.131.52.http: F 0:0(0) ack 1
08:30:48.577198 IP 10.0.4.10.2107 > 184.108.40.206.http: F 0:0(0) ack 1
08:31:07.039327 IP 10.0.4.10.2107 > 220.127.116.11.http: F 0:0(0) ack 1
08:31:43.960191 IP 10.0.4.10.2107 > 18.104.22.168.http: F 0:0(0) ack 1
This traffic happens to include both interfaces, but the last spurt from
10.0.4.10 shows up on the public side of the interface. This box runs
squid incase you were wondering why there was not a direct handoff per
packet, but other boxes with this problem are not running squid.
May I suggest someone else even try it at home :), or on a half busy
box? We _are_ honestly seeing this at different sites with different
rules, but with the common SNAT for private IP space.
We are just dumping traffic to watch using tcpdump: tcpdump -i <public
interface> -n net 10.0.0.0/8 or net 192.168.0.0/16
More information about the netfilter