<div dir="ltr"><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>So I'm wondering if it is possible to force the generation of responses with what is effectively a 'spoofed' source address?</div><div><br></div><div>Thanks!</div><div><br></div><div>- Phill</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 30 Jun 2020 at 14:24, Phill Corner <<a href="mailto:phillc@gmail.com">phillc@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Good day,<div><br></div><div>I'm new to working with StrongSwan and ambitiously trying to do a rather unusual use case.</div><div>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.<br></div><div><br></div><div>One interface is the 'outside' or normal interface and has an IP address 192.168.8.128.</div><div>The other interface is the 'inside' or protected network and has no IP address, in effect both inside and outside attached networks are using <a href="http://192.168.8.0/24" target="_blank">192.168.8.0/24</a>.</div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><div><br></div><div>[192.168.8.1] <- IPSec (dst .10) -> [StrongSwan Decrypt] <-- Clear Protocol --> [192.168.8.10]</div><div><br></div><div>Firstly, would this approach even be possible with the capabilities of StrongSwan?</div><div>If so can anyone give a suggestion on where to start?</div></div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div> I would appreciate thoughts from peers, thank you!</div><div><br></div><div>- Phill</div></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span style="color:rgb(102,102,102)">---</span><br><span style="color:rgb(102,102,102)"><font size="1"><font size="2"><b>Phillip J Corner GICSP EngTech ICTTech MIET</b></font></font></span><font size="1"><br><br></font></div></div></div></div></div></div></div></div></div></div></div></div></div>