[Swan] Help with CentOS 7/Windows 10 interoperability

[Paul Wouters]

On Wed, 12 Feb 2020, Paul Warwicker wrote:

> The Windows clients are using the built-in VPN client and a route is automatically added on a connection. It is
> using X.509 certificates which are installed correctly on the client. It is on an internal network and all
> firewalls are currently disabled. Everything is currently in the same VLAN.

If you are doing a 0.0.0.0/0 VPN tunnel, you cannot really be on the
LAN/WAN for that. It will work better if you come from external. Perhaps
only specify the specific subnet of the db server?

> The Windows client connects, authenticates and establishes an AES256 tunnel. However, the dbserver is not
> accessible from any client (neither proprietary tcp/udp based protocol tests or ICMP ping). The same test from
> vpnserver to dbserver is successful. During the test on a Windows client there is observable ESP chatter on port
> 4500.

That usually means there is an issue with ip_forwarding, rp_filter, or
NAT happening for connections that should not have NAT applied to them.
It could also be that the dbserver does not know how to route to the
IP addresses given to the VPN clients. tcpdump on the server should be
able to tell you some more based on seeing reply packets or not to/from
the dbserver.

> Feb 12 09:34:06 vpnserver pluto[50237]: "testvpn"[1] 10.2.130.187 #2: STATE_V2_IPSEC_R: IPsec SA established tunnel
> mode {ESP/NAT=>0x0fd6e1e8 <0xfe3b0d44 xfrm=AES_CBC_256-HMAC_SHA2_256_128 NATOA=none NATD=10.2.130.187:4500
> DPD=active}

So it seems there is a NAT between the VPN client and VPN server. So do
double check that the dbserver is sending reply packets for the VPN
client ranges to the VPN server (if different from its default gateway)


> The Windows connection is terminated with error 631 (The port was disconnected by the user.). This is not a
> deliberate action.

Most likely because it is not receiving any encrypted packets in reply,
and determines that the connection while established, is still not
working properly.


>         leftsubnet=0.0.0.0/0    # (1)
>         #leftsubnet=10.2.130.186/32 # specific IP of dbserver
>         #leftsubnet=10.2.130.0/24

>         rightaddresspool=10.2.130.211-10.2.130.254

It seems you are handing out IP addresses of the local LAN of the
dbserver? So the dbserver might be arping to reply to the VPN
clients, and the ipsec server is not properly doing proxy_arp ?

You could avoid this by using a seperate IP range for VPN clients,
so the dbserver would route packets to its default gateway or VPN
server for those new VPN client IP ranges.

Paul