Mobile VPN with SSL stopped connecting all of a sudden with no changes made
XTM330 12.1.3
Mobile VPN with SSL v12
VPN just stopped connecting today on some workstations. It used to work fine and no changes were made. There are three tunnels active so it's working for some. I tried various versions of VPN (12.0, 12.2, 12.5) on both Win10 and a fresh install of Win7 without OS updates.
Troubleshooting wise, I disabled SSL and TLS 1.0 only leaving 1.1 and 1.2 enabled. This being a setting in IE so I don't know how it would affect third party software but that's what I found suggested all over the place. It didn't make a difference.
The error is generated before credentials are checked. I can put in fake credentials and it generates the same error so it happens before authentication.
2020-07-21T11:32:04.281 Requesting client configuration from vpn.mydomain.com:444
2020-07-21T11:32:06.230 FAILED:2020-07-21T11:32:09.181 FAILED:Cannot perform http request 12029
2020-07-21T11:32:09.188 failed to get domain name
The only difference between Windows versions is the "http request" number with 12029 being on Win10 and 12031 on Win7
Comments
Nothing in Traffic Monitor to help understand this?
Most likely a firewall reboot will resolve it.
You can turn on diagnostic logging for SSLVPN which may show something to help:
In WSM Policy Manager: Setup -> Logging -> Diagnostic Log Level -> VPN -> SSL
In the Web UI: System -> Diagnostic Log
Set the slider to Information or higher
Reboot did not help.
Turned on Informational logging for VPNSSL. Where do I actually view the log?
Traffic Monitor
At first I thought it just wasn't showing the VPN connection with the external IP. But now I see it's not showing ANY traffic from the external IP, even though I am refreshing OWA and using TeamViewer to connect to an internal workstation where I can actually view the log. My IP is invisible. Am I missing some obvious setting you think?
By default, XTM does not log allowed packets.
One needs to select Logging on desired policies to see packets allowed by those policies in Traffic Monitor or the log servers if you have them set up.
In that case the external IP is not being denied because it doesn't show at all. I see a bunch of other Deny packets but not the one I'm testing from. Not very useful bit of information, is it?
Contact your ISP to see if they can help.
They should be able to send ping packets to that IP addr, as could a remote user.
And, if SSLVPN connections are being tried, and if the packets are getting to the firewall, one should see SSLVPN diagnostic logs in Traffic Monitor.
Since you say that you are not seeing these, it could be an ISP issue.
It'd also be worth trying from behind your firewall, on your trusted network.
-Check your "WatchGuard SSLVPN" policy and make sure any-trusted is in the FROM area.
-If it is, try connecting to the VPN from behind the firewall -- if you can get to it there, it suggests there could be a VPN issue.
If you'd like help, I'd suggest opening a ticket with support. They can assist with setting up tests and determining the issue.
-James Carson
WatchGuard Customer Support
I seriously doubt an ISP issue. The same thing is being experienced on three different ISP, even different countries. USA and India.
I am able to connect locally from within the LAN. Coming from outside, the client log just says it can't connect by http. The failure is instant, almost as if I was using the wrong IP, but if I give it the wrong IP, the error number is 12007 while when the IP is correct, the error is 12029.
Hi @PeterL
An instant failure sounds like a reset is being sent by whatever is responding. Running a packet capture on the firewall with the external interface can help determine if the traffic is even getting there.
Using firebox system manger, you can go to tools -> diagnostic tasks.
-select TcpDump from the drop down menu.
-Click the advanced options checkbox.
-Use the argument "-i eth0 host 1.2.3.4 and port 443"
(replace 1.2.3.4 with the IP your client pc is coming from, eth0 with whatever port is your external, if it's not port 0, and port 443 with whatever port your SSLVPN uses if it's not the default, 443.)
-Click to send the data to a file, and choose where it'll be saved.
-Click start task.
Now attempt to connect, and then click stop task.
You can take a look at the packet capture, and see if the data is making it to the firewall. If you need help interpreting that, one of our techs would be happy to help via a support case. Please don't post it here, as it will contain your personal IPs.
-James Carson
WatchGuard Customer Support
TcpDump taken and I do see a bunch of RST bits. But I will have to wait for support that can figure out what this means because I can't read packet captures so well.