0

I have a VPN server that tunnels traffic to a PostgreSQL database server which is otherwise unreachable from the internet. The VPN is only reachable by IPv4.

Problem

All clients can establish a VPN connection. Some clients can't connect to the database. A tcpdump reveals that the traffic times out at some point in the process.

A peculiar thing about this is that the clients - using the same notebook - can connect from their work office, but can't connect from their home office.

Attempted solutions

I followed different tutorials and instructions on how to setup a robust VPN server.

I analysed the config file, tested different settings and made sure every line in the file had a clear, well-understood and specific purpose.

I especially made sure to match the iptables rules from the official documentation. Here is my /etc/ufw/before.rules:

# User modified  
*nat  
-I POSTROUTING -m policy --pol ipsec --dir out -j ACCEPT  
-A POSTROUTING -s 192.168.169.0/24 -o eth0 -m policy --pol ipsec --dir out -j ACCEPT  
-A POSTROUTING -s 192.168.169.0/24 -o eth0 -j MASQUERADE  
COMMIT  
  
*mangle  
-A FORWARD -m policy --pol ipsec --dir in  -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360
-A FORWARD -m policy --pol ipsec --dir out -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360
COMMIT  
# End user modified

[. . .]

# User modified  
-A ufw-before-forward --match policy --pol ipsec --dir in --proto esp -s 192.168.169.0/24 -j ACCEPT  
-A ufw-before-forward --match policy --pol ipsec --dir out --proto esp -d 192.168.169.0/24 -j ACCEPT  
# End user modified

Considered solutions

Given that a successful connection is dependent on the location of the client (home office / work office) it seems very likely that either router-settings or the network-carrier cause the issue. I was able to determine that connection failures have only occurred in networks where Vodafone is the carrier.

My research revealed that a lot of people struggled with similar problems because of Vodafones DS-lite (shared virtual IPv4 address) and were able to solve their problems by upgrading to Dual Stack (real IPv4 address). The problem is: even if this would solve the problem, it would have to be setup by each client individually (not sustainable) and it looks like Vodafone might be less and less inclined to grant these requests. So the most logical thing will probably be to configure the VPN server so that it supports IPv6 and see whether that solves the problem.

Question

Do you have further suggestions on what I might try?

ffrosch
  • 111
  • 6

1 Answers1

0

I found a hint that suggested that Vodafones DS-lite technology causes further overhead and increases the packet-size. Following that lead I found somebody who was able to solve the connectivity problem by decreasing the MTU size to 1270 in iptables.

I did the same in my /etc/ufw/before.rules and also trimmed down the mangle-commands a little bit. It seems like this solved the problem! I am now waiting to get feedback from the rest of the users.

# User modified
*nat
-I POSTROUTING -m policy --pol ipsec --dir out -j ACCEPT
-A POSTROUTING -s 192.168.169.0/24 -o eth0 -m policy --pol ipsec --dir out -j ACCEPT
-A POSTROUTING -s 192.168.169.0/24 -o eth0 -j MASQUERADE
COMMIT

*mangle
-A FORWARD -m policy --pol ipsec --dir in  -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270
-A FORWARD -m policy --pol ipsec --dir out -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270
COMMIT
# End user modified

[. . .]

# User modified
-A ufw-before-forward --match policy --pol ipsec --dir in --proto esp -s 192.168.169.0/24 -j ACCEPT
-A ufw-before-forward --match policy --pol ipsec --dir out --proto esp -d 192.168.169.0/24 -j ACCEPT
# End user modified
ffrosch
  • 111
  • 6