Mobile user cannot connect (DSLITE/CGNAT?)
I have a disturbing issue with a Firebox and a mobile user. The user has the VPN client and uses VPN with SSL. It worked fine. Now the user has switched it line from DSL to fibre. The new provider uses CGNAT/DSLITE obviously. Now the connection attempts fail.
In the traffic monitor no incoming traffic is seen. However i tested if i can reach the Firebox. This test was positive. If try to connect to a random port there is a deny line in the log.
After some time while connecting i am offered to use the old configuration. And that connects. In the client log i can see some back and forth on port 443. But the connection is not usable since data does not get through.
Today we also tested a L2TP connection which was also negative.
How do i need to set up a mobile user connection under these circumstances? How can i see what is going wrong?
Other users on different ISPs can connect by VPN/SSL.
Comments
Hi @Magnus
I would generally use TCPDUMP to see what is actually making it to the firewall and seeing if it is being modified.
See:
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/fsm/log_message_learn_more_wsm.html
For SSLVPN specifically, the firewall just sends that via normal TCP/UDP ports. There's a few reasons why it might be getting dropped.
I'd use an advanced argument like "-i eth0 host IPaddress and (port 443 or icmp)" to see the traffic (replace the port with the one you're using.)
If the ISP is blocking the port you want to use, you'll need to use a different port.
If the ISP is kicking the traffic back because of the packet size being too big, you may have to lower your MTU for that connection to something the ISP will handle below the standard 1500.
If you can't figure out what's happening, I'd suggest a support case so one of our team can help determine what is happening.
-James Carson
WatchGuard Customer Support
Hi James,
i forwarded your advice to our Watchguard vendor but i did nit get a reply yet.
I was able to do some testing. On one location i have this problem. But using a G4 LTE router the connection is good. So i captured the traffic using Wireshark. Here is the log and i have only replaced the IP addresses.
Client Firebox TLSv1.3 496 Client Hello
Firebox Client TCP 54 [TCP Window Update] 443 → 51929 [ACK] Seq=1 Ack=1 Win=30016 Len=0
Client Firebox TCP 725 [TCP Retransmission] 51929 → 443 [PSH, ACK] Seq=1 Ack=1 Win=64240 Len=671
Firebox Client TCP 54 443 → 51929 [ACK] Seq=1 Ack=672 Win=31537 Len=0
Firebox Client TLSv1.3 153 Hello Retry Request, Change Cipher Spec
Client Firebox TLSv1.3 727 Change Cipher Spec, Client Hello
Firebox Client TLSv1.3 91 [TCP Previous segment not captured] , Continuation Data
Client Firebox TCP 54 [TCP Dup ACK 11#1] 51929 → 443 [ACK] Seq=1345 Ack=100 Win=64141 Len=0
Client Firebox TCP 55 [TCP Keep-Alive] 51929 → 443 [ACK] Seq=1344 Ack=100 Win=64141 Len=1
After the client send an answer to the cipher request the Firebox remains silent or sends packages which get lost. On the G4 the communication continues with a "TLSv1.3 369 Server Hello, Application Data, Application Data" package. If the Firebox sends also via the other link i have no idea why it may get lost.
Magnus
Addition: I just saw that the "client hello" packages differ in size. On thte failing link they are about half the size of the working G4 link. i am trying to figure out where that difference is.
@Magnus I'd suggest your WatchGuard Vendor open a support case so that we can look into the issue.
-James Carson
WatchGuard Customer Support