[strongSwan] Proxy ARP psudo-bridge with IPSec Transport

[Phill Corner]

So, I've done more investigating on this. I can get this working between
Win10 native Defender Advanced Firewall IPSec and StrongSwan in tunnel
mode, using my security appliance IP as the tunnel endpoint, with the
protected device IP as the remote_ts.

I also realise that the reason my transport mode policy is not working is
when StrongSwan tries to reply to the phase 1 packets from the remote
device, it cannot send the resulting packet because the source IP doesn't
exist on any local interface, hence I get a 'network is unreachable'
message.

Although it's an unusual use case, it would be preferable to get transport
mode working as intermediate firewalls along the path then have visibility
over the ultimate destination IP and port, which is actually preferable
because we can then have upstream policies restricting what actually makes
it's way over the WAN to the security appliance.

So I'm wondering if it is possible to force the generation of responses
with what is effectively a 'spoofed' source address?

Thanks!

- Phill

On Tue, 30 Jun 2020 at 14:24, Phill Corner <phillc at gmail.com> wrote:

> Good day,
>
> 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
> 192.168.8.128.
> The other interface is the 'inside' or protected network and has no IP
> address, in effect both inside and outside attached networks are using
> 192.168.8.0/24.
>
> 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 where required.
>
> 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 --> [192.168.8.10]
>
> Firstly, would this approach even be possible with the capabilities of
> StrongSwan?
> 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
> PSKs.
>
> 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!
>
> - Phill
>


-- 
---
*Phillip J Corner GICSP EngTech ICTTech MIET*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20200707/d075ee0f/attachment.html>