Score:0

strongSwan VPN tunnel (IKEv2) established but traffic times out

mx flag

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?

Score:0
mx flag

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
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.