[strongSwan] Proxy ARP psudo-bridge with IPSec Transport
phillc at gmail.com
Tue Jun 30 15:24:32 CEST 2020
I'm new to working with StrongSwan and ambitiously trying to do a rather
unusual use case.
I've got an Ubuntu Server 20.04 machine with two network interfaces which
is acting as a security appliance for a protected network of legacy devices.
One interface is the 'outside' or normal interface and has an IP address
The other interface is the 'inside' or protected network and has no IP
address, in effect both inside and outside attached networks are using
I've elected to use a psudo-bridge approach with ARP and ip_forward, hiding
the protected network from outside ARP requests, broadcast, and multicast
by default. I have this working nicely along with nftables rules on the
forward chain to control traffic, I'm also using per-interface ingress with
fwd or dup in netfilter to pass select broadcast and multicast traffic
The devices on the protected network do not support IPSec, so the scenario
I want to configure now is for IPSec between Windows 10 and StrongSwan,
decrypt, and then forward the decrypted traffic to the protected device,
and vice versa. Essentially StrongSwan acting as a sort of promiscuous
transparent IPSec proxy, building transport mode SA's on behalf of IP
addresses that aren't local, but exist on another interface.
[192.168.8.1] <- IPSec (dst .10) -> [StrongSwan Decrypt] <-- Clear Protocol
Firstly, would this approach even be possible with the capabilities of
If so can anyone give a suggestion on where to start?
The outside clients are running Windows 10 or Server 2019 and what I really
want to do is protect some of the legacy application protocols with IPSec
transport mode using the native Windows Defender Firewall capability. I've
got a test working with transport mode between the native Win10 and
StronSwan on the ubuntu machine itself using the swanctl.conf approach with
I've looked at the trap-any examples but wasn't able to get the SA to
connect properly. I've also read up a little on xfrm interfaces as a
possible way of doing this, potentially attaching the policy to an xfrm and
forcibly routing traffic to it from ingress (if that's even possible).
Worst case I thought libipsec could present a possible option in userland
but I would rather avoid that.
I would appreciate thoughts from peers, thank you!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users