Mobile VPN with SSL behind NAT
Hi,
I have a Watchguard Firebox T15, configured in Drop-in Mode. It stays behind a router, if you know FritzBox routers in Germany. I cant use Firebox as primary because it is DSL connection. A have on the router a port forwarding rule for port 443 to go firebox.
Now i need to use Mobile VPN with SSL. i have followed the steps from Wizard for configuring it. i have installed Mobile VPN client on Windows 10 machine, version 12.2.0(Build 597644). For connection i use static Public ip address and a username with pass(added user in firebox).
When i try to connect it hangs on Waiting for connection... Connecting.
Maybe i need some more ports to open, or what can be the problem?
Here is log data:
2019-11-29T14:04:01.334 Launching WatchGuard Mobile VPN with SSL client. Version 12.2.0 (Build 597644) Built:Jul 5 2019 15:15:37
2019-11-29T14:06:00.758 Requesting client configuration from xxx.xxx.xxx.xxx:443
2019-11-29T14:06:03.266 VERSION file is 5.32, client version is 5.32
2019-11-29T14:06:04.278 OVPN:>HOLD:Waiting for hold release:0
2019-11-29T14:06:04.341 OVPN:>LOG:1575032764,D,MANAGEMENT: CMD ''
2019-11-29T14:06:04.342 OVPN:>LOG:1575032764,D,MANAGEMENT: CMD 'hold release'
2019-11-29T14:06:04.343 OVPN:SUCCESS: hold release succeeded
2019-11-29T14:06:04.343 OVPN:>PASSWORD:Need 'Auth' username/password
2019-11-29T14:06:04.405 OVPN:>LOG:1575032764,D,MANAGEMENT: CMD 'username "Auth" "xxxxxxx"'
2019-11-29T14:06:04.406 OVPN:SUCCESS: 'Auth' username entered, but not yet verified
2019-11-29T14:06:04.407 OVPN:>LOG:1575032764,D,MANAGEMENT: CMD 'password [...]'
2019-11-29T14:06:04.407 OVPN:SUCCESS: 'Auth' password entered, but not yet verified
2019-11-29T14:06:04.408 OVPN:>LOG:1575032764,D,PRNG init md=SHA1 size=36
2019-11-29T14:06:04.410 OVPN:>LOG:1575032764,D,PID packet_id_init seq_backtrack=64 time_backtrack=15
2019-11-29T14:06:04.411 OVPN:>LOG:1575032764,D,PID packet_id_init seq_backtrack=64 time_backtrack=15
2019-11-29T14:06:04.412 OVPN:>LOG:1575032764,D,PID packet_id_init seq_backtrack=64 time_backtrack=15
2019-11-29T14:06:04.412 OVPN:>LOG:1575032764,D,PID packet_id_init seq_backtrack=64 time_backtrack=15
2019-11-29T14:06:04.414 OVPN:>LOG:1575032764,,Control Channel MTU parms [ L:1623 D:1210 EF:40 EB:0 ET:0 EL:3 ]
2019-11-29T14:06:04.415 OVPN:>LOG:1575032764,D,MTU DYNAMIC mtu=1450, flags=2, 1623 -> 1450
2019-11-29T14:06:04.416 OVPN:>LOG:1575032764,D,RESOLVE_REMOTE flags=0x0101 phase=1 rrs=0 sig=-1 status=0
2019-11-29T14:06:04.417 OVPN:>LOG:1575032764,,Data Channel MTU parms [ L:1623 D:1450 EF:123 EB:406 ET:0 EL:3 ]
2019-11-29T14:06:04.418 OVPN:>LOG:1575032764,D,crypto_adjust_frame_parameters: Adjusting frame parameters for crypto by 68 bytes
2019-11-29T14:06:04.419 OVPN:>LOG:1575032764,D,calc_options_string_link_mtu: link-mtu 1623 -> 1571
2019-11-29T14:06:04.420 OVPN:>LOG:1575032764,D,crypto_adjust_frame_parameters: Adjusting frame parameters for crypto by 68 bytes
2019-11-29T14:06:04.421 OVPN:>LOG:1575032764,D,calc_options_string_link_mtu: link-mtu 1623 -> 1571
2019-11-29T14:06:04.422 OVPN:>LOG:1575032764,,Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1571,tun-mtu 1500,proto TCPv4_CLIENT,cipher AES-256-CBC,auth SHA256,keysize 256,key-method 2,tls-client'
2019-11-29T14:06:04.423 OVPN:>LOG:1575032764,,Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1571,tun-mtu 1500,proto TCPv4_SERVER,cipher AES-256-CBC,auth SHA256,keysize 256,key-method 2,tls-server'
2019-11-29T14:06:04.424 OVPN:>LOG:1575032764,I,TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.1.10:443
2019-11-29T14:06:04.426 OVPN:>LOG:1575032764,,Socket Buffers: R=[65536->65536] S=[65536->65536]
2019-11-29T14:06:04.426 OVPN:>LOG:1575032764,I,Attempting to establish TCP connection with [AF_INET]192.168.1.10:443 [nonblock]
2019-11-29T14:06:04.427 OVPN:>LOG:1575032764,,MANAGEMENT: >STATE:1575032764,TCP_CONNECT,,,,,,
2019-11-29T14:06:04.428 OVPN:>STATE:1575032764,TCP_CONNECT,,,,,,
2019-11-29T14:08:04.421 Connection Closed.
Comments
What do you see in your firewall logs related to this access?
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
Hi Buce, nothing special to be mentioned.
2019-11-29 15:21:47 sslvpn =========initialization OK=========
2019-11-29 15:21:47 firewall Flush of parp:bovpn in the filter table failed
2019-11-29 15:21:47 firewall Deletion of chain parp:bovpn in table filter failed
2019-11-29 15:21:47 firewall Flush of parp:bovpn in the filter table failed
2019-11-29 15:21:47 firewall Deletion of chain parp:bovpn in table filter failed
2019-11-29 15:21:47 firewall Flush of parp:bovpn in the filter table failed
2019-11-29 15:21:47 firewall Deletion of chain parp:bovpn in table filter failed
2019-11-29 15:21:47 sslvpn Entered in sslvpn_takeaddr
2019-11-29 15:21:47 sslvpn Arguments which needs to be sent:openvpn_init 192.168.1.2 252 1 1
2019-11-29 15:21:47 sslvpn Going to open wgipc:
2019-11-29 15:21:47 sslvpn Success,Sending Data to sslvpn_firecluster:openvpn_init 192.168.1.2 252 1 1
2019-11-29 15:21:48 sslvpn Entering function sslvpn_client_event, event is 262145
2019-11-29 15:21:48 sslvpn Received Session Status Change event, current state:0x0
2019-11-29 15:21:48 sslvpn sslvpn_event, add entry, entry->virtual_ip=0.0.0.0, entry->real_ip=77.0.7.101, dropin_mode=1
2019-11-29 15:21:48 sslvpn Mobile VPN with SSL user stas logged in. Virtual IP address is 0.0.0.0. Real IP address is 77.0.7.101.
2019-11-29 15:21:48 sslvpn Entering function sslvpn_client_event, event is 33554435
I would expect the virtual IP addr to be something other than 0.0.0.0.
It should be something from the defined IP addr pool that you have set up for SSLVPN. The default is 192.168.113.0/24
The following indicates that you should have 5 concurrent licenses for SSLVPN & L2TP combined.
https://www.watchguard.com/wgrd-products/appliances-compare/17841/17846/17851
You can verify this in your Feature Key.
You can check if you have any connected VPN sessions in
. WSM Firebox System Manager -> Authentication List -> Mobile VPN Users
.Web UI -> System Status -> Authentication List
Otherwise, no idea why this is not working for you.
You can test this internally when behind the firewall by connection to the firewall IP addr.
Every time I have a Firebox behind someone else's NAT router, I set a static WAN IP on the Firebox that is on the ISP router's LAN (not in its DHCP range) and put that IP into the ISP router's DMZ. That lets all inbound ports hit the Firebox.
If my ISP router has a dynamic IP, I use DynDNS in the Firebox to give me the IP I need to hit with a public FQDN.
Gregg
Gregg Hill
Hi Gregg,
Thank you for help.
Firebox has static local IP. 192.168.1.10 on External interface.
Firebox is in Drop-in Mode. Firebox is in DMZ on ISP's router.
Also ISP's router is a DHCP Server. Whne i go to Mobile VPN with SSL Wizard. i put a range 192.168.1.0/24. is it right ?
Also i can see a connected user in WebUI System Statsu->Authentification list. it has ip 0.0.0.0. Maybe it means it can not receive the ip address ?
Stasl,
I looked up the Fritz!Box and it appears to be a DSL modem and router in one box, so this should work easily as long as there is nothing else in between the WatchGuard and the Internet other than the Fritz!Box. In my opinion, the best setup for you would be: Internet > Fritz!Box DSL port > Fritz!Box LAN > WatchGuard WAN (Eth0) > WatchGuard LAN (Eth1) > network switch with your LAN devices connected to it.
You stated, "Firebox has static local IP. 192.168.1.10 on External interface." What is the LAN side subnet of the Fritz!Box? Assuming it's a standard 192.168.1.0/24 subnet, and assuming the LAN IP of the Fritz!Box is 192.168.1.1, then the WatchGuard External interface would be 192.168.1.10, mask 255.255.255.0, and gateway 192.168.1.1 (the WatchGuard's WAN gateway is the Fritz!Box' LAN IP).
The WatchGuard's Eth0 interface should be Trusted, and the Trusted subnet cannot be the same as the WAN 192.168.1.0 subnet. The Trusted LAN should be on a non-common subnet such as 192.168.7.0/24 (not a common one used in hotels, consumer routers, etc.). Avoid common private subnets such as 192.168.0.0/24, 192.168.1.0/24, or 192.168.3.0/24, 192.168.168.0/24 (those are the most common ones I have seen, especially the first two).
The Fritz!Box should not have any port forwarding. It should have 192.168.1.10 in its DMZ. "Firebox is in Drop-in Mode. Firebox is in DMZ on ISP's router." Both look good as long as you don't have port forwarding.
"When i go to Mobile VPN with SSL Wizard. i put a range 192.168.1.0/24. is it right ?" If that is the Virtual IP Address Pool, it's definitely wrong. That needs to be a range you have nowhere else in your network and not a common one used in hotels, consumer routers, etc. I recommend 192.168.15.0/24. That subnet likely is not in use by you internally, and the third octet matches your T15 model, making it all nice and pretty. Mine is 192.168.35.0/24 to match my T35. My LAN is 192.168.16.0/24.
In the SSLVPN setup wizard, the "Firebox IP Addresses" should be a publicly-resolvable FQDN, and NOT an IP address. The reasoning behind using an FQDN is that IP addresses can get changed. WAN could be DHCP (not in your case right now), the WAN IP can change if you change service level or change ISP. If you use an FQDN, you never have to touch the setting in the WatchGuard again; you just change your public DNS. Let's assume you have "vpn.staslpublicdomainname.de" in public DNS.
With all of that in place, from a remote location, you'd open the SSLVPN client, enter the FQDN target vpn.staslpublicdomainname.de, then connect.
If you have a local Windows domain you are trying to access, then in the SSLVPN's DNS settings, put the LAN domain name and LAN DNS server. That makes connecting remote sites get the LAN DNS at work, just as local work computers do.
Gregg
Gregg Hill
Thx Greg for such a detailed answer. everything is configured as you stated. May the problem be in SSL Certificate? i assume if it is Mobile VPN with SSL, so it should be somewhere present/configured/added ?
I am now reaching resellers support for this question. Will update.
You can use the built-in SSL cert or a third-party cert. I use a wildcard cert from Namecheap.
Gregg Hill
Try hitting the SSLVPN login page first using a web browser. Can you get to it? Can you log into it? If not for either one, you won't get the agent to connect.
Try https://publicDNSforyourSSLVPN
e.g., try hitting https://vpn.staslpublicdomainname.de in a web browser...obviously using your real public FQDN!
Gregg Hill
Hi Gregg,
Yes i can open the webpage and login, where i can download the client, but only HTTP, it says certificate is not valid.
The SSLVPN agent HAS to connect using SSL/TLS. Even an untrusted self-signed cert can work, though, as long as you add the cert to the connecting computers' local cert store.
If you hit the SSLVPN login page on HTTPS, do you get prompted to add the cert? Connecting with the agent should give that prompt, too.
Gregg Hill
hi Gregg,
just got VPn working on my firebox. Thx for your help!
i dont know what was theproblem exactly, i just uploaded a clean config and followed the wizard for configuring Mobile VPN with SSL. One thing to mention, i have downloade the lient from Wathcguard website, not from firebox.
Now i still have some questions, of course if you can help me with.
One again thank you.
Stasl,
Question 2 is answered in the last paragraph of my long explanation.
Gregg Hill
Not sure if you resolved this or not. We had a problem similar this and we found a solution here. It ended up being the TAP driver. Complete solution at the StarNet Technologies link above.
The TAP driver did not solve our "Waiting for connection" issue, but it looks like it is a bug with ESET antivirus which we are currently using. Updating the Mobile VPN with SSL client app to 12.5.3 resolved the issue for us. Our XTM850 does not hand out that version client even with the latest OS for that model, but our clients M470 running v12.5.3.B616762 (update 3) now hands that version out.
The VPN client app v12.5.3 version can also be downloaded in this ESET article - https://support.eset.com/en/kb7470-watchguard-mobile-vpn-connection-issue-with-eset-endpoint-antivirus-eset-endpoint-security
v12.5.3.B616762 (update 3) ????
"The VPN client app v12.5.3 version can also be downloaded in this ESET article...."
The SSLVPN client can be downloaded directly from WatchGuard's site. Go here https://watchguardsupport.secure.force.com/software/and pick a Firebox that supports 12.5.3, and the SSLVPN agent will be on its download page. Or, click this link http://cdn.watchguard.com/SoftwareCenter/Files/MUVPN_SSL/12_5_3/WG-MVPN-SSL_12_5_3.exe
Gregg Hill
Hi @trifecta
Generally, I wouldn't recommend using the newer TAP adapter, as it's known to cause problems in Windows. Issues related to "waiting for connection" vary widely, so there really isn't a blanket fix. If this is an ongoing issue, I'd suggest that you create a support case so that one of our techs can take a look at your logs and address whatever issues they find.
@StarNet_Actual I'd appreciate it if you could please refrain from posting your article without a full understanding of the customer's issue. If the newer TAP adapter was a fix-all, I can assure you it'd be in the current release of our VPN client.
-James Carson
WatchGuard Customer Support
@James_Carson
That was rude. At least @StarNet_Actual was trying to help. How about post a list of possible solutions or better yet have Watchguard build a better SSL client so we don't have all of these issues.
"...please refrain from posting your article" is not really rude. For one thing, the newer TAP adapter is "known to cause problems in Windows" as James noted. Second, that user is promoting his/her own web site and business over WatchGuard's, likely in the hope of gaining business. If it were NOT for potential personal profit, @StarNet_Actual could simply have posted the STEPS here, instead of posting a link to his/her web site. This is not the only thread where that article has been quoted by @StarNet_Actual.
Gregg Hill