[strongSwan] Site to site VPN initiated from a NAT router

[Zachary Cutlip]

I think I got it working. 

I’m not sure if there is a better way, or if this is perhaps the canonical way of doing it, but here’s what I did. Please let me know if this isn’t the normal way to accomplish this.

I had assumed traffic from the wifi clients (10.88.88.0) needed to be sent to the MASQUERADE target on the VPN client so they could be rewritten to appear as if they originated from that host before being tunneled. What I ended up doing is instead adding the 10.88.88.0/24 network to the VPN client’s leftsubnet and the remote server’s rightsubne, allowing those packets to be tunneled as-is. I also added forwarding and masquerading iptables rules on the server so that the 10.88.88.0 packets could be properly masqueraded on that end.

When the ipsec connection is brought down, NAT masquerading automatically resumes on the local box, and it behaves like an ordinary NAT router. That’s a nice bonus because I’ll need to authenticate through some networks’ captive portals before the ipsec connection can be established.

Happy to post configs for anyone who’s interested.




> On Mar 13, 2018, at 6:59 AM, Noel Kuntze <noel.kuntze+strongswan-users-ml at thermi.consulting> wrote:
> 
> You should stop looking at `iptables -L` and use `iptables-save` instead. It is a much better tool for it, in any regard.
> 
> Please provide the output of `ipsec statusall`, `iptables-save -c`, `ip a`, `ip r show table all` and `ip ru`.
> 
> Kind regards
> 
> Noel
> 
> On 13.03.2018 08:41, Zachary Cutlip wrote:
>> I’ve tweaked my iptables rules, and now traffic from the strongswan client box gets routed through the tunnel as expected. Also wifi client (10.88.88.0) traffic now gets routed, where it wasn’t before. However, that traffic still isn’t going through the tunnel.
>> 
>> Here are the iptables rules when the ipsec connection is established:
>> 
>> $ sudo iptables -L
>> Chain INPUT (policy ACCEPT)
>> target     prot opt source               destination
>> ACCEPT     all  --  anywhere             10.19.48.2           policy match dir in pol ipsec reqid 1 proto esp
>> 
>> Chain FORWARD (policy ACCEPT)
>> target     prot opt source               destination
>> ACCEPT     all  --  anywhere             10.19.48.2           policy match dir in pol ipsec reqid 1 proto esp
>> ACCEPT     all  --  10.19.48.2           anywhere             policy match dir out pol ipsec reqid 1 proto esp
>> 
>> Chain OUTPUT (policy ACCEPT)
>> target     prot opt source               destination
>> ACCEPT     all  --  10.19.48.2           anywhere             policy match dir out pol ipsec reqid 1 proto esp
>> 
>> $ sudo iptables -t nat -L
>> Chain PREROUTING (policy ACCEPT)
>> target     prot opt source               destination
>> 
>> Chain INPUT (policy ACCEPT)
>> target     prot opt source               destination
>> 
>> Chain OUTPUT (policy ACCEPT)
>> target     prot opt source               destination
>> 
>> Chain POSTROUTING (policy ACCEPT)
>> target     prot opt source               destination
>> ACCEPT     all  --  10.88.88.0/24        anywhere             policy match dir out pol ipsec
>> MASQUERADE  all  --  10.88.88.0/24        anywhere
>> 
>> 
>>> On Mar 12, 2018, at 7:36 PM, Zachary Cutlip <uid000 at icloud.com> wrote:
>>> 
>>> Hello,
>>> 
>>> I’m trying to set up an IPSec VPN that’s a little different from most projects I’ve seen documented.
>>> 
>>> I’m building a NAT router on Debian that I plan to travel with. I guess you might say my strongswan use case is sort of a hybrid between road warrior & site-to-site.
>>> 
>>> I’m confused on how to set up ipsec.conf and iptables such that all wifi clients on connecting to the NAT router/WiFi AP get their traffic routed over the tunnel.
>>> 
>>> Here are some details:
>>> 
>>> The Debian box has two interfaces
>>> - wan0, internet facing, configured via DHCP via whatever network its connected to
>>> - lan0, WiFi interface in AP mode with hostapd, 10.88.88.1/24, 
>>> (There is also a third interface for management: eth0:10.99.99.1)
>>> 
>>> dnsmasq gives out DHCP configuration to wifi clients over lan0.
>>> 
>>> I’m connecting to a strongswan instance hosted on digital ocean with a fixed IP address.
>>> 
>>> When I take the box out of NAT router mode by flushing IPtables, I can initiate a connection to the remote instance, and traffic originating from the Debian box seems to go over the tunnel as expected. If I have iptables set up to do NAT routing, and then initiate the VPN connection, two things happen:
>>> 1. Traffic from the Debian box (such as traceroute 8.8.8.8) is no longer routed over the tunnel.
>>> 2. Traffic from the wifi clients doesn’t get routed at all.
>>> 
>>> I feel like this should be pretty straightforward; I’m just missing something. Any advice?
>>> 
>>> Here’s what my iptables looks like when the NAT router is working, and there are no ipsec connections:
>>> 
>>> sudo iptables -L
>>> Chain INPUT (policy ACCEPT)
>>> target     prot opt source               destination
>>> 
>>> Chain FORWARD (policy ACCEPT)
>>> target     prot opt source               destination
>>> ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
>>> ACCEPT     all  --  anywhere             anywhere
>>> 
>>> Chain OUTPUT (policy ACCEPT)
>>> target     prot opt source               destination
>>> 
>>> $ sudo iptables -t nat -L
>>> Chain PREROUTING (policy ACCEPT)
>>> target     prot opt source               destination
>>> 
>>> Chain INPUT (policy ACCEPT)
>>> target     prot opt source               destination
>>> 
>>> Chain OUTPUT (policy ACCEPT)
>>> target     prot opt source               destination
>>> 
>>> Chain POSTROUTING (policy ACCEPT)
>>> target     prot opt source               destination
>>> MASQUERADE  all  --  anywhere             anywhere
>>> 
>>> Here’s the ipsec.conf generated by Trail of Bits’s AlgoVPN (I added the passthroughs):
>>> 
>>> $ cat ipsec.conf
>>> conn ikev2-165.x.x.x
>>>   fragmentation=yes
>>>   rekey=no
>>>   dpdaction=clear
>>>   keyexchange=ikev2
>>>   compress=no
>>>   dpddelay=35s
>>> 
>>>   ike=aes128gcm16-prfsha512-ecp256,aes128-sha2_512-prfsha512-ecp256,aes128-sha2_384-prfsha384-ecp256!
>>>   esp=aes128gcm16-ecp256,aes128-sha2_512-prfsha512-ecp256!
>>> 
>>>   right=165.x.x.x
>>>   rightid=165.x.x.x
>>>   rightsubnet=0.0.0.0/0
>>>   rightauth=pubkey
>>> 
>>>   leftsourceip=%config
>>>   leftauth=pubkey
>>>   leftcert=zach.crt
>>>   leftfirewall=yes
>>>   left=%defaultroute
>>> 
>>>   auto=add
>>> 
>>> conn mgmt-passthrough
>>>   leftsubnet=10.99.99.0/24 # Replace with your LAN subnet
>>>   rightsubnet=10.99.99.0/24 # Replac with your LAND subnet
>>>   authby=never # No authentication necessary
>>>   type=pass # passthrough
>>>   auto=route # no need to ipsec up lan-passthrough
>>> 
>>> 
>>> conn wifi-passthrough
>>>   leftsubnet=10.88.88.0/24 # Replace with your LAN subnet
>>>   rightsubnet=10.88.88.0/24 # Replac with your LAND subnet
>>>   authby=never # No authentication necessary
>>>   type=pass # passthrough
>>>   auto=route # no need to ipsec up lan-passthrough
>>> 
>>> 
>