[strongSwan] L2TP/IPSec Passthrough - Interfaces?

[Noel Kuntze]

Did you also DNAT the ESP traffic, if you somehow don't use UDPENCAP, as you should with NAT?

On 06.06.2017 22:08, Tom Rymes wrote:
> On 06/06/2017 3:46 PM, Noel Kuntze wrote:
>> Hello Tom,
>>
>> On 02.06.2017 21:12, Tom Rymes wrote:
>>> We are running StrongSWAN as part of an IPFire router distribution. Strongswan handles multiple tunnels via the WAN interface, and that interface has multiple public IPs associated with it.
>>>
>>> We are also trying to pass L2TP/IPSec through the router to a Windows RRAS server for the purpose of establishing roadwarrior-type VPN connections to one of the other IP Addresses.
>>>
>>> Currently, this is not working, and it seems that it is because StrongSwan is trying to handle the IPSec traffic, instead of passing it through to the windows server.
>>
>> If you want to port forward traffic, you need to DNAT it to another host. If you don't DNAT it, the traffic will be handled locally, so charon does the right thing and so does the kernel.
>> This is a PEBKAC problem. Unless you DNAT traffic that is destined to your machine to other hosts, traffic will be handled locally.
>
> I don't doubt that this is a PEBKAC problem (most of my problems are), but it's not that particular PEBKAC problem! We have DNATed the traffic to another host, but the traffic is not arriving at the other host. After various efforts to diagnose why this was so, I began to think that perhaps the traffic was still being handled by Strongswan in spite of the DNAT somehow.
>
>>> After digging through the docs a little, it looks to me that we need to specify the "charon.interfaces_use" directive in the configuration to limit StrongSwan to only one of the configured IP Addresses.
>>
>> No, that's wrong. That will only make charon drop the packets and then they're gone.
>
> OK, thank you. We'll test it out just for good measure anyway, but I won't expect anything.
>
> This leaves us looking at an issue with IPFire's firewall setup failing to properly forward IPSec traffic, so I will pursue that avenue moving forward, unless something I wrote above changes your mind.
>
> Tom


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170606/e955a2c9/attachment-0001.sig>