Date: Mon, 29 Jun 2015 09:49:10 +0200 From: Ian FREISLICH <ian.freislich@capeaugusta.com> To: Milan Obuch <freebsd-pf@dino.sk> Cc: Daniel Hartmeier <daniel@benzedrine.ch>, freebsd-pf@freebsd.org Subject: Re: Large scale NAT with PF - some weird problem Message-ID: <E1Z9ToU-000Ph3-KT@clue.co.za> In-Reply-To: <20150629094317.5a0cd61a@zeta.dino.sk> References: <20150629094317.5a0cd61a@zeta.dino.sk> <20150620182432.62797ec5@zeta.dino.sk> <20150619091857.304b707b@zeta.dino.sk> <14e119e8fa8.2755.abfb21602af57f30a7457738c46ad3ae@capeaugusta.com> <E1Z6dHz-0000uu-D8@clue.co.za> <E1Z6eVg-0000yz-Ar@clue.co.za> <20150621195753.7b162633@zeta.dino.sk> <E1Z7Ixx-0006K1-5p@clue.co.za> <E1Z7K1Y-0006Ph-ON@clue.co.za> <20150623112331.668395d1@zeta.dino.sk> <20150628100609.635544e0@zeta.dino.sk> <20150629065838.GA13722@insomnia.benzedrine.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
Milan Obuch wrote: > On Mon, 29 Jun 2015 08:58:38 +0200 > Daniel Hartmeier <daniel@benzedrine.ch> wrote: > = > > On Sun, Jun 28, 2015 at 10:06:09AM +0200, Milan Obuch wrote: > > = > > > So, now I am at 10.2-PRERELEASE, r284884, and the issue is still > > > here. It is totally weird, just change of IP the device is being > > > natted to makes the issue disappear for this particular customer, > > > but as soon as this exact IP is used again, the issue is here again. > > = > > I'd go over the entire network config (pf.conf, pfctl -sa, rc.conf, > > netstat -anr, ifconfig, arp -an) and look for any mistake, like a > > typo or a netmask which isn't what you thought it is (like on an > > alias), or for any weirdness related to that IP address. > > = > > Daniel > = > Thanks for hint, there is some logic in there, however > = > grep <apparently.offending.ip.address> /etc/* > = > yields nothing, it is never mentioned in any config, just as part of > pool in pf.conf statement > = > nat on $if_ext from <net_int> to any -> $pool_ext round-robin sticky-add= ress > = > It is not mentioned in 'pfctl -sa' output, 'arp -an' output, > 'netstat -anr' output... nowhere. > = > I did not mention this box runs quagga for configuring network, mainly > routing via OSPF, but I do not think it is relevant to the problem I > see as this is basically userland process communicating with forwarding > path in kernel to configure routing, nothing else, and, naturally, it > does not work with this particular IP either. I should have seen it > otherwise in some of above mentioned commands output, I think. > = > Just to repeat myself a bit, when this problematic state occurs, some > intenal IP is translated to this one offending public IP, and > communication is broken in such a way I see no returning packets from > outside world on uplink interface in tcpdump even if I know they are > there because I can ping some other box outside where I can verify that > and they are there... > = > I just found some other strange, to me, thing - in 'pfctl -sa' output, > section SOURCE TRACKING NODES, almost all entries are in form > = > <one internal IP net_int table> -> <one external IP from $pool_ext> ( st= ates = ..., connections ..., rate ... ) > = > but there are some of them with first IP being public, second one > 0.0.0.0 - where they could come from? Also, there are only couple of > them, but in one is something even a bit more weird - in parens is > 'states 4294967295', which seems a bit absurd to me, also, worth to > mention, it is 0xffffffff in hexadecimal, and this looks like some > underflow issue in the code. Try making your pool smaller. With the number of NAT states you mentioned earlier, you should easily manage with a /24. Ian -- = Ian Freislich
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1Z9ToU-000Ph3-KT>