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

[Noel Kuntze]

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
>>
>>

-------------- 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/20180313/70372231/attachment.sig>