I am watching the StrongSwan lists, even though not using it frequently anymore. Today I came across an interesting case from one of the users. I will not disclose his identity, but the case was very nice.
The story is like this:
*let’s imagine all boxes run linux, gw and vpn server run strongswan for ipsec
a. the GW establishing s2s ipsec tunnel with the vpn server – this happens for many/all of the IP addresses behind the GW, _except_ the client (as represented in the picture)
b. the GW acts also as a masquerading nat box, translating all ip addresses behind it to its public ip address (IP3 in the picture)
c. the client is supposed to establish remote-access ipsec connections to the vpn server
* problem: c. does not happen if a. is taking place: if the s2s tunnel establishing is active between IP3 and IP4, then the remote-access connection between client and server is not established
Now: how can we help this guy?
1. My initial idea was to dismiss his dilemma and ask him to configure proper traffic selectors. Unfortunately, this is not working for him, as the GW does masquerading, and according to the very nice Kernel netfilter arch, all packets look the same for the ipsec engine 
2. To double-check, I’ve been looking for the netfilter picture.
http://www.netfilter.org/documentation/HOWTO/netfilter-hacking-HOWTO-3.html
http://www.docum.org/docum.org/kptd/ (thank you, tyrant! )
So I was thinking that maybe he could put some more specific rules into the forwarding chain, and overcome the masquerading issue? Our goal is to trick the IKE/IPsec packets coming from the client in _not_ reaching the GW’s ipsec engine.
Any other ideas?
Later edit:
Just got the feedback from the guy. It’s working. What he did in order to overtake this interesting situation was to add bypass rules on the GW machine, in order to convince this machine to automatically forward the packets from client to vpn server, immediately after natting them, without passing them through the ipsec engine
ip xfrm policy add dir out src 0.0.0.0/0 dst 0.0.0.0/0 proto udp dport 500 priority <some low number>
The solution looks/is very very simple, but to get here I still had to query an old friend (remember vmp? ) and do some digging into netfilter :) It paid off
One more happy “ipsec friend” Iuha!
