Hello Steven, Take a look at what the connmark plugin[1] of strongSwan does. I think doing the same fixes your problem. Or switch to strongSwan right away and use the plugin. [1] https://wiki.strongswan.org/projects/strongswan/wiki/Connmark Kind regards Noel On 12.07.2017 21:35, Rajcan, Steven L wrote: > 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 > > -- GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
Attachment:
signature.asc
Description: OpenPGP digital signature
