Score:0

Why only a few TCP packets arrive at destination on port 3306 through an IPsec VPN tunnel?

ky flag

This question was off-topic on Networkengineering and the recommendation was to post it here. So, here we go...

When connected to a network via a VPN tunnel (IPsec/L2TP), I can normally access a MySQL server host via SSH on port 22, but have critical connection problems when building a MySQL connection to the server on the default port 3306. I realised that only a very, very few number of packets get through on port 3306, and when they do get through I can even build a successful MySQL connection. After many tests, I could reduce the problem to a network issue. Plese find below the respective configuration and the latest tests I performed to isolate the issue. For the sake of completeness: When locally connected to the target network (e.g. on subnet 172.29.1.0/24) it works like a charm.

System configuration on target network:

  • VPN Server: Ubiquiti UDM Pro | Protocol: L2TP | IP: 10.1.1.1 | Subnet of VPN clients: 10.4.4.0/24
  • MySQL Server: Running on Photon4 on VMWare ESXi | IP: 10.1.1.82

System configuration on source network:

  • Host: Windows 10 | Subnet: 172.27.0.0/16
  • VPN Connection: Windows WAN Miniport Adapeter | Type: L2TP/IPsec | IP: 10.4.4.1

Network tests and results:

  • Test of TCP connection to target host on port 22: always works
$ telnet 10.1.1.82 22
Trying 10.1.1.82...
Connected to 10.1.1.82.
Escape character is '^]'.
SSH-2.0-OpenSSH_8.8
  • Test of TCP connection to target host on port 3306: almost never works
# 99% of the cases
$ telnet 10.1.1.82 3306
Trying 10.1.1.82...
telnet: Unable to connect to remote host: Resource temporarily unavailable

# 1% of the cases
$ telnet 10.1.1.82 3306
Trying 10.1.1.82...
Connected to 10.1.1.82.
Escape character is '^]'.
5.5.5-10.7.3-MariaDBOoaxW+m9'V]R`k{J=2#mysql_native_password
  • It is even possible to build a successful MySQL connection after several attempts, but just after that no further packets get through:
$ while true; do mysql -h 10.1.1.82 -u <USER> -p<PASSWORD>; sleep 1; done
ERROR 2002 (HY000): Can't connect to MySQL server on '10.1.1.82' (115)
ERROR 2002 (HY000): Can't connect to MySQL server on '10.1.1.82' (115)
ERROR 2002 (HY000): Can't connect to MySQL server on '10.1.1.82' (115)
(... Meanwhile, at the Hall of Justice...)
ERROR 2002 (HY000): Can't connect to MySQL server on '10.1.1.82' (115)
ERROR 2002 (HY000): Can't connect to MySQL server on '10.1.1.82' (115)
ERROR 2002 (HY000): Can't connect to MySQL server on '10.1.1.82' (115)
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 6
Server version: 10.7.3-MariaDB Source distribution

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> select 1;
ERROR 2013 (HY000): Lost connection to MySQL server during query
MariaDB [(none)]> select 1;
ERROR 2006 (HY000): MySQL server has gone away
ERROR 2002 (HY000): Can't connect to MySQL server on '10.1.1.82' (115)
ERROR: Can't connect to the server
unknown [(none)]>
  • I just realised that the tests above may be more likely to succeed after some period of rest or a reboot of the target host.

Now I need your help. What can be causing this issue and how can I further investigate it? It seems to occur independent of the local network infrastructure, since it happens even when connected to a mobile hotspot. If you need any further details, just let me know. Many thanks in advance!

Nikita Kipriyanov avatar
za flag
Sounds like problems with [pMTUd](https://en.wikipedia.org/wiki/Path_MTU_Discovery). Do you block ICMP? Don't do that. Try to capture the traffic and see if there are lost packets and what are cases they are lost.
Score:0
ky flag

I've managed to fix the issue myself and would like to post the answer here for future reference.

This very specific traffic, i.e. MySQL connection on port 3306 through a VPN tunnel, is wrongly identified by the UDM Pro as a threat. Disabling the category "Exploit" in the Threat Management configuration solved the issue.

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.