Hello, I have created IPsec policies using transport mode that allow systems behind a NAT(PAT) router to connect to a public system. The issue I am having is on a public system with established IPsec tunnels to systems behind a PAT (Port-Address-Translation) router. These routers multiplex systems behind a single IPV4 address. The IPsec SAs are created properly and I am able to send data from these PAT system to the public system through the IPsec tunnels in most scenarios. However, it is possible that frames sent from two or more PAT systems arrive at the public server stack with the same source port, same source IP, same destination port, and same destination IP. This occurs because the PAT router cannot modify the original TCP or UDP payload encapsulated in the ESP frame. In these scenarios, the stack on the public system gets confused and cannot map replies to those frame back through the correct IPsec tunnel of the PAT system. Consider two PAT systems attempting a TCP connection to the same public server but each happens to use the same local port of 45000. PAT1 system IP addr: 192.168.0.1 PAT2 system IP addr 192.168.0.2 PAT router public IP addr 20.20.20.10 Public system IP addr: 20.20.20.20 Note that the original TCP frame, sent by the PATx system is encapsulated in a UDP/ESP frame and is therefore, not modified by the PAT router. PAT1 [192.168.0.1:45000,20.20.20.20:80] --> PAT Router [ 10.10.10.10] -> public system [20.20.20.20:80] PAT2 [192.168.0.2:45000,20.20.20.20:80] --> PAT Router [ 10.10.10.10] -> public system [20.20.20.20:80] The original IP of the PAT systems is NAT'ed to that of the PAT router and the post-transform, inbound frames arriving at the public system stack are identical for both endpoints. [10.10.10.10:4500,20.20.20.20:90] When testing this scenario, the first PAT system establish the TCP connection properly. The second PAT system also connects but only a single TCP connection is established on the public system. An iptables log seems to indicate that the second TCP connection replaces the first. We have discovered that other platforms handle this scenario automatically on the public system by modifying the source port on the inbound, post-transform frame before it is sent up the stack. Thus the stack sees a unique frame for every TCP and UDP dialogue with the PAT endpoints. The reply frame then contains the modified source port which is restored by the OS to the original source port and is directed back through the original IPsec tunnel. So the questions is, can the Linux kernel do the same or something similar? I looked at the xfrm routines and could not find anything that indicates that it could. Please note that using tunnel mode instead of transport mode is not an option for our situation. Any help would be appreciated. Thanks Steve Rajcan mailto:Steven.Rajcan@xxxxxxxxxx
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
