Options

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

  • Options
    james.carsonjames.carson Moderator, WatchGuard Representative

    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

  • Options

    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

  • Options

    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.

  • Options
    james.carsonjames.carson Moderator, WatchGuard Representative

    @Magnus I'd suggest your WatchGuard Vendor open a support case so that we can look into the issue.

    -James Carson
    WatchGuard Customer Support

Sign In to comment.