Date: Sun, 21 May 2017 22:41:30 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ipfw@FreeBSD.org Subject: [Bug 219316] Wildcard matching of ipfw flow tables Message-ID: <bug-219316-7515-HHycrfVaTh@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-219316-7515@https.bugs.freebsd.org/bugzilla/> References: <bug-219316-7515@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219316 --- Comment #12 from lutz@donnerhacke.de --- Ah, I missed the previous comment. >>1) Large Scale NAT violates the happy eyeball requirement, that a given c= lient >> should always use the same external IP while communicating to a given se= rvice. > On what timescale? Forever? As long as the client has the same (CGN) IP (from 10.64.0.0/10). > If a client is idle for 5 minutes (no sessions) can > it start using a new IP? No. That violates the happy-eyeball contraint. Several web services bind the session to the external visible IP. If this IP does change, the customer ha= s to login again and again. We already made this mistake (using LSN). >>2) Mapping all customers to a single IP does not work either, because the= re >> are too much connections originating by those customers. > How may remote addresses are you talking too? > You can reuse the same address and port to may different remote addresses= .. That would surprise me. Such an implementation would require dynamic memory= for the NAT tables. I do not see such a memory usage on my FreeBSD machines. I = did see such an effect on a CISCO ASA. See: https://lutz.donnerhacke.de/Blog/High-memory-with-extended-PAT-on-ASA >> Consequently a deterministically selected group of clients has to share = the >> same NAT table using a single external IP. A typical approach is to use= =20 >> wildcards to match the right NAT instance: > you just said that "Mapping all customers to a single IP does not work .." > and yet that is what you show here.. Am I misreading it? The classical NAT setting does not distinguish between the client IPs and therefore does either have a single IP or LSN. My setup partitions the clients by their IPs and then I use a "single IP per partition" NAT. > How many clients are we talking about here? 10? 100? 1000? 10K? 100K? 1M? > and are these clients all on separate hardware? or are they coming from a > small number of session aggregator machines? Currently I have ~10k clients per hardware, the setup scales horizontally. = If I get more clients, I add additional machines and tell them in DHCP to use a different gateway (next machine). >> add 2100 nat 100 ipv4 from 100.64.0.0:255.192.0.63 to any xmit ext out >> add 2101 nat 101 ipv4 from 100.64.0.1:255.192.0.63 to any xmit ext out >> add 2102 nat 102 ipv4 from 100.64.0.2:255.192.0.63 to any xmit ext out >> >> This approach is inefficient, tables could help. But tables does not sup= port >> wildcard masking of lookup data. With such an wildcard mask, especially = the >> flow tables could greatly improve performance. > I don't quite understand this bit > my memory is that you can have a table > 100.64.0.0:255.192.0.63 0 > 100.64.0.1:255.192.0.63 1 ... > nat tablearg ip from table (x) to any out xmit XX0 You are right. That's the setup I'm used before switching to this flow based NAT. I only used the very early setup to demonstrate the problem. My fault. > what am I missing? You are missing the privacy expectations and the Law Enforcement Agencies. = For privacy, we like to use different external IPs for the same client reaching different services. That's why flows. For LEAs we need to tell exactly which user war involved in a specific sess= ion, so we need to log some data about NAT. This is an overwhelming large amount= of data, so we like to push down the necessary logs. This can be done by allocation blocks of ports to a customer instead of individual ports. In order to carefully assign such port ranges, they need to be large (at le= ast 300 per customer in order to access Google Maps without errors). That's why= we need to heavily reuse port (ranges) and this requires multiple NAT tables p= er customer. The only separation method left is to include the destination address, port and protocol. That's why we switched to flows. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-219316-7515-HHycrfVaTh>