M370 to M390 | Mobile SSLVPN Fails now? "Waiting for initial response from server"
Greetings all.
Recently we just updated our older M370 for a new M390 to make use of those 10G Fiber module addins you can get for them as a part of infrastructure upgrades.
However, after slotting the new unit in and letting it run, getting the old configuration ported over, then activating the feature key. The SSL VPN seems to be misbehaving and people cant get in.
I've checked some other elements such as our DNS Filtering solution and it doesn't seem to be the cause. AV was ruled out as well for the time being.
I'm seeing the following on the client side:
2024-03-04T09:54:22.271 Requesting client configuration from {Our IPv4 Address}:444
2024-03-04T09:54:24.272 VERSION file is 5.36, client version is 5.36
2024-03-04T09:54:24.787 LaunchOpenVPN: openvpn full command-line(first 8 chars): "C:\Prog, length: 248
2024-03-04T09:54:24.788 LaunchOpenVPN: vpn config full path(first 8 chars): C:\Users, length: 60
2024-03-04T09:54:25.315 OVPN:>HOLD:Waiting for hold release:0
2024-03-04T09:54:25.394 OVPN:>LOG:1709564065,D,MANAGEMENT: CMD ''
2024-03-04T09:54:25.395 OVPN:>LOG:1709564065,D,MANAGEMENT: CMD 'hold release'
2024-03-04T09:54:25.396 OVPN:SUCCESS: hold release succeeded
2024-03-04T09:54:25.397 OVPN:>PASSWORD:Need 'Auth' username/password
2024-03-04T09:54:25.475 OVPN:>LOG:1709564065,D,MANAGEMENT: CMD 'username "Auth" "{My Username}"'
2024-03-04T09:54:25.476 OVPN:SUCCESS: 'Auth' username entered, but not yet verified
2024-03-04T09:54:25.477 OVPN:>LOG:1709564065,D,MANAGEMENT: CMD 'password [...]'
2024-03-04T09:54:25.477 OVPN:SUCCESS: 'Auth' password entered, but not yet verified
2024-03-04T09:54:25.478 OVPN:>LOG:1709564065,I,TCP/UDP: Preserving recently used remote address: [AF_INET]{Our IPv4 Address}:444
2024-03-04T09:54:25.480 OVPN:>LOG:1709564065,,Socket Buffers: R=[65536->65536] S=[65536->65536]
2024-03-04T09:54:25.481 OVPN:>LOG:1709564065,I,Attempting to establish TCP connection with [AF_INET]{Our IPv4 Address}:444 [nonblock]
2024-03-04T09:54:25.481 OVPN:>LOG:1709564065,,MANAGEMENT: >STATE:1709564065,TCP_CONNECT,,,,,,
2024-03-04T09:54:25.481 OVPN:>STATE:1709564065,TCP_CONNECT,,,,,,
2024-03-04T09:54:26.488 OVPN:>LOG:1709564066,I,TCP connection established with [AF_INET]{Our IPv4 Address}:444
2024-03-04T09:54:26.489 OVPN:>LOG:1709564066,I,TCP_CLIENT link local: (not bound)
2024-03-04T09:54:26.491 OVPN:>LOG:1709564066,I,TCP_CLIENT link remote: [AF_INET]{Our IPv4 Address}:444
2024-03-04T09:54:26.492 OVPN:>LOG:1709564066,,MANAGEMENT: >STATE:1709564066,WAIT,,,,,,
2024-03-04T09:54:26.493 OVPN:>STATE:1709564066,WAIT,,,,,,
2024-03-04T09:54:45.644 OVPN:>LOG:1709564085,N,read TCP_CLIENT: Unknown error (code=10060)
2024-03-04T09:54:45.645 OVPN:>LOG:1709564085,N,Connection reset, restarting [-1]
2024-03-04T09:54:45.646 OVPN:>LOG:1709564085,I,SIGUSR1[soft,connection-reset] received, process restarting
2024-03-04T09:54:45.647 OVPN:>LOG:1709564085,,MANAGEMENT: >STATE:1709564085,RECONNECTING,connection-reset,,,,,
Please note these were two separate authentication attempts, the errors are the same but the time mismatch is expected, I had to redo it because I timed out and needed to log back in
On the Firebox's End (Logging set to Debug):
2024-03-04 10:01:47 sslvpn Received Session Status Change event, current state:0x0 2024-03-04 10:01:47 sslvpn Session delete event, entry->virtual_ip=0.0.0.0, entry->real_ip=172.16.1.175, dropin_mode=0 2024-03-04 10:01:47 sslvpn Entering function sslvpn_client_event, event is 2097153 2024-03-04 10:01:47 sslvpn Entering function sslvpn_client_event, event is 67108867 2024-03-04 10:02:08 sslvpn get_sslvpn_counter, Unable to find interface sslvpn0 and tun0
From what i'm finding, it cant bind to the sslvpn0 interface (or at least. that's my guess from the 0.0.0.0 IP assignment and unable to find interface error).
Configuration is set up to authenticate against AD, not Firebox-DB, running on version 12.10.B685791 as well. I can access the web interface to download the VPN client at [MyIPAddress]:444
VPN client is on the version provided by the Firebox, not the old outdated one as well.
Let me know if additional details are needed, I do plan on a restart of the system during lunch time to see if that helps address any errors as I have not restarted it since I added the feature key to the system.
Edit: Realized theres an "Ask a question" section. Whoops. First time using this forum. My bad.
Just a random tank doing networking, don't mind me
Comments
Have you tried connecting a SSLVPN client from behind your firewall?
That should remove any Internet related issues.
Bruce,
Thanks for your reply.
Yes. In fact the two tests above were done internally on the company network behind the firewall to rule out that possibility. I have two work from home users who brought it initially to my attention that they couldn't connect.
Just a random tank doing networking, don't mind me
Try the old outdated SSLVPN client...
Interesting. Using the outdated version, 12.2 it connected up immediately with no issues. This would explain why some of my other end users who are always on the VPN haven't reached out to me regarding this issue.
When 12.10 from the new firebox is used: the problem occurs.
Just a random tank doing networking, don't mind me
Now you have some real facts to provide should you open a support case on this.
Let us know if a firewall reboot resolves the issue with the 12.10 client.
Restart did indeed fix it. Much appreciated for the help Bruce.
For those following along later who're googling this issue themselves:
Seems if you're getting these errors and recently have migrated from an older firebox to a new one: test your old VPN client. If it connects but the new one doesn't then try restarting the unit. Looks like it fixes the issue. I'd reckon this is because I uploaded the configuration file before my feature key was added but I'd say restart your Firebox after the feature key is installed or updated at any point.
Other folks i've found online say that certain Antiviruses can be a factor, make sure you test internally and ensure those are ruled out as well.
Edit: Clarity, Grammatical typos
Just a random tank doing networking, don't mind me
The OpenVPN TAP driver was updated between those versions -- if you're running into a problem with just the new version, you likely have something blocking that adapter from sending network traffic (local AV, local firewall, etc.) or potentially more than one TAP driver installed.
The older SSLVPN TAP will work, but you will see the driver signing warning when installing it (since the certificate that signed it has expired) and performance may be slightly worse, but it should continue to work if you choose to use it.
-James Carson
WatchGuard Customer Support