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.

  • @StasI said:
    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.

  • @StasI said:
    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.

    1. How can i upload a new version of Mobile VPN client to firebox? so i can download it from firebox itself, not from watchguard website.
    2. Should i make extra policies to access network shares from a VPN connected PC? i need to get to a server shared folder "\fileserver\public", from a VPN machine that has virtual IP 192.168.113.2

    One again thank you.

    1. you can't - it is bundled with XTM
    2. you don't need an extra policy to allow this access. The default "Allow SSLVPN-Users" policy should allow this access
  • edited December 2019

    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.

  • edited April 2020

    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

  • james.carsonjames.carson Moderator, WatchGuard Representative
    edited April 2020

    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.

  • @jvidmar said:
    @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

Sign In to comment.