i have kernel 2.6.9 and that's true i see packets form internal network 192.168.0.0/16 appearing on externel iface besides all network should be natted form a range of 192.168.x.y to 212.128.a.b. It seems some packets missed the nat rule on iptables or connection tracking doesnt catch som packets when my box is busy. Anyone got this behavior? El MiÃrcoles 16 Marzo 2005 13:49, James MacLean escribiÃ: > 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 > test in. > > Some more dump, just for fun :)... > > 08:30:11.100766 IP 10.0.5.243.1270 > 63.250.195.12.http: F > 3707121597:3707121597(0) ack 502138606 win 64970 > 08:30:17.054926 IP 142.177.51.51.36703 > 63.250.195.12.http: S > 978075472:978075472(0) win 5840 <mss 1460,sackOK,timestamp 1145498148 > 0,nop,wscale 2> > 08:30:17.136969 IP 63.250.195.12.http > 142.177.51.51.36703: S > 1839730991:1839730991(0) ack 978075473 win 65535 <mss 1460,nop,wscale > 1,nop,nop,timestamp 1702037157 1145498148> > 08:30:17.136998 IP 142.177.51.51.36703 > 63.250.195.12.http: . ack 1 win > 1460 <nop,nop,timestamp 1145498230 1702037157> > 08:30:17.137710 IP 142.177.51.51.36703 > 63.250.195.12.http: P > 1:552(551) ack 1 win 1460 <nop,nop,timestamp 1145498230 1702037157> > 08:30:17.221654 IP 63.250.195.12.http > 142.177.51.51.36703: F > 521:521(0) ack 552 win 33304 <nop,nop,timestamp 1702037165 1145498230> > 08:30:17.221695 IP 142.177.51.51.36703 > 63.250.195.12.http: . ack 1 win > 1460 <nop,nop,timestamp 1145498314 1702037157> > 08:30:17.221777 IP 63.250.195.12.http > 142.177.51.51.36703: P > 1:521(520) ack 552 win 33304 <nop,nop,timestamp 1702037165 1145498230> > 08:30:17.221799 IP 142.177.51.51.36703 > 63.250.195.12.http: . ack 522 > win 1728 <nop,nop,timestamp 1145498315 1702037165> > 08:30:17.222489 IP 142.177.51.51.36703 > 63.250.195.12.http: F > 552:552(0) ack 522 win 1728 <nop,nop,timestamp 1145498315 1702037165> > 08:30:17.304268 IP 63.250.195.12.http > 142.177.51.51.36703: . ack 553 > win 33304 <nop,nop,timestamp 1702037174 1145498315> > 08:30:32.472154 IP 10.0.4.10.2107 > 63.250.195.12.http: F > 3949942874:3949942874(0) ack 724796989 win 63967 > 08:30:34.730636 IP 10.0.4.10.2107 > 63.250.195.12.http: F 0:0(0) ack 1 > win 63967 > 08:30:39.345472 IP 10.0.4.10.2107 > 63.250.195.12.http: F 0:0(0) ack 1 > win 63967 > 08:30:48.577198 IP 10.0.4.10.2107 > 63.250.195.12.http: F 0:0(0) ack 1 > win 63967 > 08:31:07.039327 IP 10.0.4.10.2107 > 63.250.195.12.http: F 0:0(0) ack 1 > win 63967 > 08:31:43.960191 IP 10.0.4.10.2107 > 63.250.195.12.http: F 0:0(0) ack 1 > win 63967 > > 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 > > thanks again, > JES -- ------------------------------------------------- Clister UAH -------------------------------------------------
