strongSwan client can connect to the internet (through the VPN) but cannot SSH to VPN server or other clients on the VPN subnet

Question

I wrote a strongSwan guide a while back which I followed.

I then installed isc-dhcp-server and configured strongSwan for DHCP.

Everything works fine except clients cannot SSH to the VPN server or other clients on the VPN subnet (10.0.2.0/24).

I can’t figure out what I am missing. I followed the exact same steps on another server and clients can SSH to the VPN server and other clients (same config but strongSwan version 5.5.1 vs 5.7.2).

$ ipsec --version

Linux strongSwan U5.7.2/K4.19.0-8-amd64

$ cat /etc/ipsec.conf

config setup
  charondebug="ike 1, knl 1, cfg 0"
  uniqueids=never

conn ikev2
  auto=add
  compress=no
  type=tunnel
  keyexchange=ikev2
  fragmentation=yes
  forceencaps=yes
  ike=aes256gcm16-sha384-modp3072!
  esp=aes256gcm16-sha384-modp3072!
  dpdaction=clear
  dpddelay=300s
  rekey=no
  left=%any
  leftid=my-vpn.com
  leftcert=vpn-server.crt
  leftsendcert=always
  leftsubnet=0.0.0.0/0
  right=%any
  rightid=%any
  rightauth=eap-tls
  rightdns=1.1.1.1,1.0.0.1
  rightsourceip=%dhcp
  rightsendcert=never
  eap_identity=%identity

$ cat /etc/strongswan.conf

libtls {
  suites = TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
}
charon {
  plugins {
    dhcp {
      force_server_address = yes
      identity_lease = yes
      interface = ens3
      load = yes
      server = 10.0.2.255
    }
  }
}

$ cat /etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug ens3
iface ens3 inet static
    # Redacted

# The VPN DHCP network interface
auto ens3:1
iface ens3:1 inet static
    address 10.0.2.1
    netmask 255.255.255.0

$ cat /etc/dhcp/dhcpd.conf

default-lease-time 600;
max-lease-time 7200;
ddns-update-style none;
subnet 10.0.2.0 netmask 255.255.255.0 {
  range 10.0.2.10 10.0.2.254;
}

$ iptables-save

# Generated by xtables-save v1.8.2 on Sat May  2 08:16:30 2020
*mangle
:PREROUTING ACCEPT [33047:26369989]
:INPUT ACCEPT [15485:16310786]
:FORWARD ACCEPT [16291:10015891]
:OUTPUT ACCEPT [13361:11160535]
:POSTROUTING ACCEPT [29612:21159798]
-A FORWARD -p tcp -m policy --dir in --pol ipsec -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360
-A FORWARD -p tcp -m policy --dir out --pol ipsec -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360
COMMIT
# Completed on Sat May  2 08:16:30 2020
# Generated by xtables-save v1.8.2 on Sat May  2 08:16:30 2020
*nat
:PREROUTING ACCEPT [1644:68855]
:INPUT ACCEPT [58:4901]
:POSTROUTING ACCEPT [124:8399]
:OUTPUT ACCEPT [138:9996]
-A POSTROUTING -s 10.0.2.0/24 -o ens3 -m policy --dir out --pol ipsec -j ACCEPT
-A POSTROUTING -s 10.0.2.0/24 -o ens3 -j MASQUERADE
COMMIT
# Completed on Sat May  2 08:16:30 2020
# Generated by xtables-save v1.8.2 on Sat May  2 08:16:30 2020
*filter
:INPUT DROP [82:5220]
:FORWARD DROP [32:18146]
:OUTPUT DROP [17:1198]
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p udp -m udp --sport 67:68 --dport 67:68 -m state --state NEW -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m udp --dport 500 -j ACCEPT
-A INPUT -p udp -m udp --dport 4500 -j ACCEPT
-A INPUT -p udp -m udp --sport 67:68 --dport 67:68 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 --tcp-flags FIN,SYN,RST,ACK SYN -m connlimit --connlimit-above 50 --connlimit-mask 32 --connlimit-saddr -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -m tcp --dport 443 --tcp-flags FIN,SYN,RST,ACK SYN -m connlimit --connlimit-above 50 --connlimit-mask 32 --connlimit-saddr -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW -m limit --limit 60/sec --limit-burst 20 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -m conntrack --ctstate NEW -m limit --limit 60/sec --limit-burst 20 -j ACCEPT
-A FORWARD -s 10.0.2.0/24 -m policy --dir in --pol ipsec --proto esp -j ACCEPT
-A FORWARD -d 10.0.2.0/24 -m policy --dir out --pol ipsec --proto esp -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 53 -m state --state NEW -j ACCEPT
-A OUTPUT -p udp -m udp --dport 53 -m state --state NEW -j ACCEPT
-A OUTPUT -p udp -m udp --sport 67:68 --dport 67:68 -m state --state NEW -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 443 -m state --state NEW -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -p udp -m udp --sport 67:68 --dport 67:68 -m state --state NEW -j ACCEPT
-A OUTPUT -p udp -m udp --dport 123 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
COMMIT
# Completed on Sat May  2 08:16:30 2020
# Generated by xtables-save v1.8.2 on Sat May  2 08:16:30 2020
*raw
:PREROUTING ACCEPT [33047:26369989]
:OUTPUT ACCEPT [13361:11160535]
COMMIT
# Completed on Sat May  2 08:16:30 2020

$ sysctl -p

net.ipv4.ip_forward = 1
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

Do you have the _farp_ plugin loaded? Also, what clients do you use? Some are unable to connect to the server's public IP address while the VPN is up. — ecdsa, May 04 '20 at 07:06
Hey @ecdsa. Thanks so much for your help. I installed strongSwan using `apt install strongswan` and didn’t enable the `farp` plugin. On the server where clients can connect to other clients, same config and plugin (as far as I know unless defaults have changed) but older version of strongSwan. Same clients... Linux strongSwan version `5.5.1` and macOS using provisioning profiles. — sunknudsen, May 04 '20 at 12:05
You'll need the _farp_ plugin on the server so other clients in the same subnet send packets for IPs handed out by the DHCP server to the VPN server (see [here](https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling) for details). And macOS is one of the clients that can't access the VPN server on its public IP address while the VPN is up (i.e. you'll have to use the private address in the `10.0.2.0/24` subnet to access it). — ecdsa, May 04 '20 at 14:30
Thanks for the follow-up @ecdsa. Has something changed between versions `5.5.1` and `5.7.2`, both installed using `apt install strongswan`? I don’t recall having done anything specific to the `farp` plugin on the server where things are working. — sunknudsen, May 04 '20 at 15:20
@ecdsa Running `ipsec statusall` on the server where clients cannot connect to clients reveals that the `farp` plugin is loaded. — sunknudsen, May 04 '20 at 15:25
@ecdsa What I am trying to accomplish is for a client with IP `10.0.2.10` (for example) to be able to SSH to the VPN server with IP `10.0.2.1` and to other clients within the `10.0.2.0/24` subnet. This used to work out of the box but somehow I can’t get this to work on a new server even though I am using the same config. I am probably missing something. Thanks again for your help. — sunknudsen, May 04 '20 at 16:55
You'll have to follow the traffic (counters, captures, iptables tracing) to see where it might get stuck or incorrectly handled. — ecdsa, May 05 '20 at 06:16
Thanks @ecdsa. Unfortunately, this is beyond my level of knowledge (I tried investigating this route before reaching out on serverfault). Do you have someone you could recommend who could help? Btw, please check your at strongswan. — sunknudsen, May 05 '20 at 10:04

score 0 · Accepted Answer · answered May 24 '20 at 11:15

Shout-out to Noel who solved this issue.

Using dnsmasq vs ISC DHCP as the DHCP server and the following config, I can now SSH from client to server.

/etc/dnsmasq.d/01-dhcp-loopback.conf

interface=lo
dhcp-range=10.0.2.10,10.0.2.254,255.255.255.0
port=0

/etc/strongswan.conf

charon {
  load_modular = yes
  plugins {
    include strongswan.d/charon/*.conf
  }
}

include strongswan.d/*.conf

/etc/strongswan.d/charon/dhcp.conf

dhcp {
    force_server_address = yes
    identity_lease = yes
    interface = lo
    load = yes
    server = 10.0.2.1
}

Also, the following iptables rules are not longer necessary.

-A INPUT -p udp -m udp --sport 67:68 --dport 67:68 -m state --state NEW -j ACCEPT
-A OUTPUT -p udp -m udp --sport 67:68 --dport 67:68 -m state --state NEW -j ACCEPT

strongSwan client can connect to the internet (through the VPN) but cannot SSH to VPN server or other clients on the VPN subnet

1 Answers1