Date: Mon, 29 Jun 2015 10:00:40 +0200 From: Milan Obuch <freebsd-pf@dino.sk> To: Ian FREISLICH <ian.freislich@capeaugusta.com> Cc: Daniel Hartmeier <daniel@benzedrine.ch>, freebsd-pf@freebsd.org Subject: Re: Large scale NAT with PF - some weird problem Message-ID: <20150629100040.218c23a2@zeta.dino.sk> In-Reply-To: <E1Z9ToU-000Ph3-KT@clue.co.za> 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> <E1Z9ToU-000Ph3-KT@clue.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 29 Jun 2015 09:49:10 +0200 Ian FREISLICH <ian.freislich@capeaugusta.com> wrote: > 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-address > > > > 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> > > ( states > ..., 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. > OK, I changed pool_ext size from /23 to /24... just would like to know, why should this have desired effect, please... So I am going to observe how it works, but I am sure I had this pool defined for some maybe years and did not receive any complaint until just recently. Regards, Milan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150629100040.218c23a2>