[strongSwan] strongSwan IKEv2 VPN for NATed clients
Roger Ignazio
rggn+ssu at protonmail.ch
Sun Jan 26 19:51:27 CET 2020
I seem to be a bit closer with the following strongSwan config, in that I can
now send traffic from the USG across the tunnel and over my ISP (versus dropping
the traffic altogether).
config setup
uniqueids = no
conn %default
left = %defaultroute
leftfirewall = yes
leftsourceip = %config4
type = tunnel
dpdaction = restart
dpddelay = 30s
dpdtimeout = 90s
auto = start
conn vpn
keyexchange = ikev2
leftauth = eap-mschapv2
eap_identity = [REDACTED]
right = [REDACTED]
rightid = %any
rightsubnet = 0.0.0.0/0
rightauth = pubkey
traceroute over the tunnel (was also working last night)
admin at ubnt# sudo traceroute -s 0.0.0.0 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1) from 0.0.0.0, 30 hops max, 38 byte packets
1 [VPN PROVIDER HOP 1] ([VPN PROVIDER HOP 1) 6.867 ms 6.951 ms 6.970 ms
2 [VPN PROVIDER HOP 2] ([VPN PROVIDER HOP 2) 7.073 ms 7.127 ms 7.697 ms
3 host.my-tss.com (198.8.80.6) 6.864 ms 7.534 ms 7.001 ms
4 six.as13335.com (206.81.81.10) 7.840 ms 7.844 ms 7.650 ms
5 one.one.one.one (1.1.1.1) 6.589 ms 7.008 ms 7.420 ms
traceroute sourced from the LAN IP (doesn't go over the tunnel)
admin at ubnt# sudo traceroute -s 192.168.1.1 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1) from 192.168.1.1, 30 hops max, 38 byte packets
1 [ISP HOP] ([ISP IP) 2.111 ms 1.656 ms 2.054 ms
2 [ISP HOP] ([ISP HOP]) 1.793 ms 1.836 ms 2.225 ms
3 ae2---0.cor01.[ISP] ([ISP]) 5.894 ms 5.862 ms 5.943 ms
4 ae4---0.cor01.[ISP] ([ISP]) 6.948 ms 6.279 ms 5.888 ms
5 ae0---0.cbr01.[ISP] ([ISP]) 5.537 ms 5.639 ms 5.595 ms
6 ae51.edge6.Seattle1.Level3.net (4.35.242.37) 6.031 ms 13.660 ms 17.525 ms
7 4.69.137.201 (4.69.137.201) 15.384 ms 4.69.137.205 (4.69.137.205) 5.957 ms 4.69.137.201 (4.69.137.201) 6.081 ms
8 4.59.234.98 (4.59.234.98) 6.071 ms 6.276 ms 6.090 ms
9 one.one.one.one (1.1.1.1) 6.109 ms 6.018 ms 6.133 ms
iptables rules added by leftfirewall=yes and removing leftsubnet
+ -A INPUT -d 10.6.7.72/32 -i eth0 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
+ -A FORWARD -d 10.6.7.72/32 -i eth0 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
+ -A FORWARD -s 10.6.7.72/32 -o eth0 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
+ -A OUTPUT -s 10.6.7.72/32 -o eth0 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
I've also tried creating a NAT masquerade rule from 192.168.1.0/24 to 10.0.0.0/8
but that just seems to break things. Clients behind the router still lose access
to the gateway (can't ping 192.168.1.1)
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, January 25, 2020 7:56 PM, Roger Ignazio <rggn+ssu at protonmail.ch> wrote:
> I'm attempting to connect to a VPN service from a Unifi Security Gateway (USG)
> running stronSwan and am running into an issue that I haven't been able to
> solve. When the tunnel comes up, all clients on the LAN lose connectivity to the
> gateway (192.168.1.1), but I'm able to send traffic over the tunnel from the USG
> itself, but only when connected with a console cable.
>
> What I'm trying to do, which I've done on Cisco ASAs before, is to connect the
> USG to a VPN service and allow all NATed clients on my network to use the
> tunnel, so that they don't each need to run their own VPN client.
>
> The setup looks like this:
>
> - DHCP WAN IP assigned by my ISP on eth0
> - USG-managed LAN (192.168.1.0/24) on eth1
> - NAT rule to masquerade 192.168.1.0/24 to eth0
> - strongSwan configs for connecting to the VPN service using IKEv2
> - The VPN service hands out DHCP addresses to clients in 10.0.0.0/8, NATing them
> to the VPN server's public IP
>
> I've done some trial-and-error on the values for leftsubnet and rightsubnet,
> thinking the routed connection could be a problem, but each time I change either
> side from 0.0.0.0/0, I get undesired results and can't send traffic over the
> tunnel from the USG.
>
> My config files and debug output are included below, with some bits redacted.
> 10.6.5.222 is the DHCP address assigned by the VPN provider.
>
> Thoughts anyone?
>
>
> ### Contents of /etc/strongswan.d/charon.conf
>
> charon {
> interfaces_use = eth0
> }
>
> ### Contents of /config/vpn-ipsec.conf
>
> config setup
> uniqueids = no
>
> conn %default
> left = %defaultroute # use the public IP (DHCP) assigned by the ISP
> leftsourceip = %config4 # use a vpn-assigned client IPv4 address
> leftsubnet = 0.0.0.0/0 # all internet-bound traffic
> leftfirewall = yes # internal net is NATed
> type = tunnel
> dpdaction = restart # restart if the remote peer is dead
> dpddelay = 30s # check peer liveness if no traffic is sent
> dpdtimeout = 90s # peer is dead after 3 missed messages
> auto = route # bring up the SA for interesting traffic
>
> conn vpn
> keyexchange = ikev2
> leftauth = eap-mschapv2
> eap_identity = [REDACTED]
> right = [VPN SERVER HOSTNAME]
> rightid = %any # any ID but requires pubkey to be valid
> rightsubnet = 0.0.0.0/0 # all internet-bound traffic
> rightauth = pubkey # requires a valid CA cert in /etc/ipsec.d/cacerts
>
> ### Debugging
>
> admin at ubnt# sudo ipsec statusall
> Status of IKE charon daemon (strongSwan 5.2.2, Linux 3.10.107-UBNT, mips64):
> uptime: 18 seconds, since Jan 25 17:47:13 2020
> malloc: sbrk 413696, mmap 0, used 296664, free 117032
> worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
> loaded plugins: charon ldap sqlite pkcs11 aes des sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs8 pem openssl agent xcbc cmac ctr ccm gcm curl attr kernel-netlink resolve socket-default stroke vici updown eap-identity eap-md5 eap-mschapv2 eap-radius eap-tls xauth-generic xauth-eap addrblock
> Listening IP addresses:
> [MY WAN IP]
> Connections:
> vpn: %any...[VPN SERVER PUBLIC HOSTNAME] IKEv2, dpddelay=30s
> vpn: local: uses EAP_MSCHAPV2 authentication with EAP identity '[REDACTED]'
> vpn: remote: uses public key authentication
> vpn: child: 0.0.0.0/0 === 0.0.0.0/0 TUNNEL, dpdaction=restart
> Routed Connections:
> vpn{1}: ROUTED, TUNNEL
> vpn{1}: 0.0.0.0/0 === 0.0.0.0/0
> Security Associations (1 up, 0 connecting):
> vpn[1]: ESTABLISHED 16 seconds ago, MY_WAN_IP[MY_WAN_IP]...VPN_SERVER_PUBLIC_IP[VPN_SERVER_PUBLIC_HOSTNAME]
> vpn[1]: IKEv2 SPIs: [...]* [...], EAP reauthentication in 2 hours
> vpn[1]: IKE proposal: AES_GCM_16_128/PRF_HMAC_SHA2_256/ECP_256
> vpn{1}: INSTALLED, TUNNEL, ESP SPIs: c68a7389_i cf685805_o
> vpn{1}: AES_CBC_256/HMAC_SHA1_96, 1368 bytes_i (18 pkts, 2s ago), 3353 bytes_o (41 pkts, 2s ago), rekeying in 45 minutes
> vpn{1}: 10.6.5.222/32 === 0.0.0.0/0
>
> admin at ubnt:~$ show vpn ipsec state
> src [MY WAN IP] dst [VPN SERVER PUBLIC IP]
> proto esp spi 0xcf685805 reqid 1 mode tunnel
> replay-window 32 flag af-unspec
> auth-trunc hmac(sha1) [...] 96
> enc cbc(aes) [...]
> src [VPN SERVER PUBLIC IP] dst [MY WAN IP]
> proto esp spi 0xc68a7389 reqid 1 mode tunnel
> replay-window 32 flag af-unspec
> auth-trunc hmac(sha1) [...] 96
> enc cbc(aes) [...]
>
> admin at ubnt:~$ show vpn ipsec sa
> vpn: #1, ESTABLISHED, IKEv2, [...]:[...]
> local '[MY WAN IP]' @ [MY WAN IP]
> remote '[VPN SERVER PUBLIC HOSTNAME]' @ [VPN SERVER PUBLIC IP]
> AES_GCM_16-128/PRF_HMAC_SHA2_256/ECP_256
> established 196s ago, reauth in 9759s
> vpn: #1, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA1_96
> installed 197 ago, rekeying in 2571s, expires in 3404s
> in [...], 5392 bytes, 55 packets, 24s ago
> out [...], 21790 bytes, 241 packets, 9s ago
> local 10.6.5.222/32
> remote 0.0.0.0/0
>
> admin at ubnt:~$ sudo ip route
> default via [MY WAN IP] dev eth0 proto zebra
> 10.6.5.222 dev eth0 proto kernel scope link src 10.6.5.222
> [MY WAN SUBNET] dev eth0 proto kernel scope link src [MY WAN IP]
> 127.0.0.0/8 dev lo proto kernel scope link src 127.0.0.1
> 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1
>
> admin at ubnt:~$ traceroute 1.1.1.1
> traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 38 byte packets
> 1 [VPN PROVIDER HOP 1] ([VPN PROVIDER HOP 1]) 6.853 ms 7.129 ms 7.431 ms
> 2 [VPN PROVIDER HOP 2] ([VPN PROVIDER HOP 2]) 8.499 ms 7.029 ms 7.174 ms
> 3 host.my-tss.com (198.8.80.6) 6.785 ms 7.188 ms 6.909 ms
> 4 six.as13335.com (206.81.81.10) 7.418 ms 36.268 ms 9.986 ms
> 5 one.one.one.one (1.1.1.1) 7.683 ms 6.768 ms 7.529 ms
>
> me at laptop $ ping 192.168.1.1
> PING 192.168.1.1 (192.168.1.1): 56 data bytes
> Request timeout for icmp_seq 0
> Request timeout for icmp_seq 1
> Request timeout for icmp_seq 2
> ping: sendto: Host is down
More information about the Users
mailing list