Hello everyone, I've just come back from vacation and picked this up again. I've not yet found a pretty solution to the issues that are present when using NAT on a large scale and communicating with sources that require clients to communicate from the same external IP. I had hoped we wouldn't need to reserve ports as per the last idea as it is wasteful so I've looked at it again. I turned towards the source code of netfilter used in Linux to see how they implemented their SAME target (deprecated), and later (current) "persistent" flag as this works very well in a crowded NAT (lots of clients easily and quickly filling up port slots of several external IPs at once). They previously hashed both source and destination IP but this caused the aforementioned issues (essentially endpoint dependent). The current implementation, and has been current for a few years now, is that they only care about the client source IP and match that always to the same external IP. It is extremely important that ports and destinations are not taken into consideration as it breaks many services. The idea is therefor that if we have seen a client before, and we have assigned an external IP to that client, we should aim to keep assigning that same external IP to that client for all future connections, regardless of ports. My understanding per the previous comments and the construction of the 4-tuple is that the user will get the same external IP if both the source IP and source port match a previous connection. This unfortunately breaks functionality (tested to verify) with most services that open several connections from a client IP, from several source ports, expecting to see all connections coming from the same IP. The above can also occur if the client IP is assigned to a typical residential CPE, where multiple connections originate from the same client IP. In which case users attempting to use something like IP-verified two-factor authentication (banks) behind their CPE will fail.
An addition to the above but not a functional requirement, in order to alleviate the number of occupied ports for a given external IP so we increase the chances of having an available port for a client who needs to reuse it is that new users added to the first least-used external IP in the pool. However, this part falls within NAT address and port allocation and could be added as a separate algorithm. I'm struggling to see a good implementation other than messing with the actual session keys and I'll happily accept suggestions
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12060): https://lists.fd.io/g/vpp-dev/message/12060 Mute This Topic: https://lists.fd.io/mt/28785710/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
