> This might be best answered by Matus since it regards NAT, but I'll throw it > out there for the whole group. > > The endpoint-dependent feature of the NAT plugin – Endpoint address AND port > dependent I presume from the 6-tuple description of it – allows us to map the > same internal source IP and port to the same external IP when targeting a > certain past destination IP AND port, correct? > My concern is more of the situations where services initially create a > connection to one endpoint address, and then create another session to > another endpoint address, expecting the same source address to match the > client. > > Client opens a connection to endpoint X using external IP A, which proceeds > to instruct client to open a session to endpoint Y, both endpoints share the > same backend and expect the client to have IP A but since it's a new session > and we're doing dynamic NAT, the client ends up with external IP B, breaking > the chain. Many services depend on this. > > The idea is that when a new NAT source IP is seen, that we reserve a certain > number of internal ports for that IP to the same number of external ports on > a single IP, so all connections originating from that NAT source IP will > always have the same external IP, thus allowing for endpoint services to not > lose track of client due to IP mismatch, which breaks service.
Yes, and this is the reason why the IETF recommendeds against it, and recommends the use of endpoint independent mapping. In one sense, us at your peril, in the other sense, given that we’ve run out of Ipv4 addresses, that will have consequences for applications too. Address and port dependent mapping obviously has the great benefit of using the address/port space efficiently. One option we discussed, which I’m happy to encourage patches for, is to make the NAT mode, NAT traversal aware. E.g. it detects a STUN packet and makes that connection have endpoint independent mapping (for some time period). Inverse we could only do address and port dependent mappings for “applications” (aka UDP/TCP ports) we knew were safe. Opinions welcome! Cheers, Ole
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11638): https://lists.fd.io/g/vpp-dev/message/11638 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] -=-=-=-=-=-=-=-=-=-=-=-
