VPN Packet Loss - IPSEC
-
Hi.
We have a single pfSense system handling IPSEC Site to Site and L2TP VPN traffic on our network.
Our site to site traffic works as expected, and we can communicate to all devices as you would expect, however when a user connects to the L2TP VPN and attempts to communicate with a site over the site to site links, some packets seem to drop, but not all of them.
For example, all ICMP traffic is flowing through, and we know there is a route both ways, however, when trying something like SMB traffic, you can seemingly only make one request before the connection is dropped, i.e. allowing you query the shares on a server, after that, you can't query shares or open a folder again. Another example is 443 traffic to devices, traffic can get through to some devices at the site, but not others.
The firewall rules that exist on L2TP are "allow all" and the rules on the IPSec tunnel are similar, in that there is an allow all rule for IPv4 traffic.
I've got screenshots of the rules, but can't upload them for now.
Communication between L2TP devices is fine, as is communication between L2TP to LAN Clients and vice versa.
Has anyone got any suggestions as to what this might be, we know it's not routing as we have a route there and traceroute works fine, but we can't see anywhere in the firewall where this is being blocked.
Thanks
-
@SJones560 said in VPN Packet Loss - IPSEC:
some packets seem to drop, but not all of them.
What percentage? With TCP, there will always be some packet loss, as that is how flow control works. The device sends more and more traffic, until loss occurs and then it throttles back, on the assumption that the loss was due to congestion.
-
Thanks for your reply.
It's not intermittent packet loss; it's permanent packet loss.
It's a tough problem to explain, but the best wording we have you can make an initial connection when establishing a connection to an SQL server, we can log in, the login is successful however any queries that are subsequently run against the database fail with TCP timeout.
A similar issue was seen when using VNC over TCP (5900) the connection was made, and we could log in successfully, however, we could not get the image of the screen which was being set back over TCP.
We ran Wireshark against on these devices looking at these ports etc. and could see the traffic attempting multiple re-transmissions, however, when connecting from the LAN side, all traffic and data flow as expected and we could see the missing packets.
-
As promised, here are the images of our Firewall rules.
IPSEC:
L2TP: