Let me put it another way. Think about IPsec responder like a TCP server and IPsec initiator like a TCP client. The server doesn’t send anything to the client until it gets an initial request from it; once the initial request arrives, the server learns the client’s IP address and port from it and responds to this address and port. If the client is behind a NAT on its own side, the server knows nothing about it, as it cannot see any other address of the client than the one from which the traffic from the client arrives to it.
In IPsec, if the initiator wishes to use a tunnel mode SA, it suggests the traffic selectors (at least the source and destination addresses, but it may also specify a particular IP protocol and source and destination ports if the notion of ports is supported by that protocol) and the responder either accepts the suggestions compatible with its local policy templates and rejects those that are not. Other scenarios are possible too, but let’s stay concentrated.
With tunnel mode, you can use any combination of addresses as traffic selectors, not related to the peers’ own addresses at all. So you can use any private address at the responder router, and any private address at the initiator router, and create a tunnel mode SA to forward traffic between the two. Then, you configure EoIP to use this pair of private addresses, and you’re good. The price to pay for this comfort is some 20 bytes per packet occupied by the inner IP header.
If the initiator wishes to use transport mode, the source and destination addresses of the traffic selector are given, because they must be the peers’ addresses. Effectively, the transport mode security association only encrypts the traffic between the two peers’ addresses. So much like in the TCP case, each peer uses its own private address on WAN, and uses the public IP of the remote peer because that’s from where it can see the traffic to arrive, and that’s where it has to send it so that the remote side NAT would deliver it to the right destination.
Of course there may be other initiators behind 80.92.246.248, but that doesn’t matter unless they connect to the same responder. And since there is NAT, the IPsec transport packets may not arrive to the responder from port 4500 but from any other UDP port the ISP’s NAT has chosen to use. So as long as the responder sends its traffic to that address and port, the traffic will reach the client, again same like in the TCP case. But the ISP’s NAT will, still like in the TCP case, replace its own public IP with the client’s private IP as it forwards the packet.
The EoIP knows nothing about any IPsec. It sends its transport packets to the remote-address, and they are intercepted by the IPsec traffic selector, encrypted, and sent via the SA. If the SA doesn’t exist, e.g. before the IPsec session is established after reboot, the EoIP packets are sent without encryption to the remote public address, and the NAT of the ISP drops them because they are unexpected for it. This can be avoided by a specific IPsec or routing configuration.
What can be a problem is when multiple initiators connect from behind the same public IP to the same responder. Whereas the security associations can be distinguished from each other, because they come from different ports at the client NAT side, the traffic selectors may overlap unless they use specific protocol and port, so the first policy to be generated from a template intercepts the matching packets.
So if you have some other initiator (like your PC) connected to the LAN of the router behind 80.92.246.248, or merely behind 80.92.246.248, and that initiator suggests a traffic selector with no restriction on IP protocol, the EoIP traffic sent by the responder may get “stolen” by that traffic selector and get delivered to the wrong initiator.
I.e. transport mode provides a more efficient use of packet space, but it has the above mentioned limitations.
