Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ssl vpn client crash: PAGE_FAULT_IN_NONPAGED_AREA

I just stood up an XG210, I have a remote access SSL VPN set up but some of my client machines crash when connecting. We get this bluescreen:

 

All the affected computers are Dell laptops running Windows 7 Pro. Crashes happen with both the Sophos client downloaded from the user portal and OpenVPN 2.4.3-I601. I updated Windows and all drivers. This isn't happening on all my clients, and I don't see any hardware or software differences between machines that crash and those that don't.

I tried a few things, safe mode, then clean boot - adding services one at a time. The OpenVPN Interactive Service is the one that corresponds to the crash. Running the client without that service running appears to connect, gets an IP, but I can't access the network I'm connecting to.

So I looked into that service; my understanding is that lets the client do some things that require it to run as admin without running as admin. I tried running the OpenVPN client as an admin with the service disabled - crash.

Looking at the logs, there were a few ROUTE ADD commands, that fail when the service is not running. I tried entering them manually, it crashes shortly after entering

route add 0.0.0.0 mask 128.0.0.0 10.81.234.5 (when the VPN has the 'use as default gateway' checked)

or route add <internal IP> mask 255.255.255.0 10.81.234.5 (when default gateway not checked)

 

it looks like adding a route that already exists might be the issue? I don't understand why it works on some computers and not others.

 

I would sure appreciate any thoughts anyone has on this.



This thread was automatically locked due to age.
Parents
  • Ian, did you run the install as "run as Administrator"?

    "route add" are added from SSL VPN automatically using Administrative privileges.

    Thanks

  • Hi Luk,

     

    I let Windows prompt for elevation the first time I installed; I just un-installed and re-installed running the installer as administrator, no change in behavior.

     

    The VPN client log on one of my working machines has these entries:

    Thu Jul 13 13:32:05 2017 Set TAP-Windows TUN subnet mode network/local/netmask = 10.81.234.0/10.81.234.8/255.255.255.0 [SUCCEEDED]
    Thu Jul 13 13:32:05 2017 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.81.234.8/255.255.255.0 on interface {911CF463-13DB-4726-A3F1-D25B34E42BCE} [DHCP-serv: 10.81.234.254, lease-time: 31536000]
    Thu Jul 13 13:32:05 2017 Successful ARP Flush on interface [20] {911CF463-13DB-4726-A3F1-D25B34E42BCE}
    Thu Jul 13 13:32:05 2017 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
    Thu Jul 13 13:32:05 2017 MANAGEMENT: >STATE:1499967125,ASSIGN_IP,,10.81.234.8,,,,
    Thu Jul 13 13:32:09 2017 TEST ROUTES: 3/3 succeeded len=2 ret=1 a=0 u/d=up
    Thu Jul 13 13:32:09 2017 C:\Windows\system32\route.exe ADD <external IP> MASK 255.255.255.255 172.18.65.1
    Thu Jul 13 13:32:09 2017 Route addition via service succeeded
    Thu Jul 13 13:32:09 2017 C:\Windows\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.81.234.5
    Thu Jul 13 13:32:09 2017 Route addition via service succeeded
    Thu Jul 13 13:32:09 2017 C:\Windows\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.81.234.5
    Thu Jul 13 13:32:09 2017 Route addition via service succeeded

    which look to me like it's adding routes at runtime. I can induce the Stop 0x50 error by manually adding a route that already exists - at least that's what I think is happening, it's not always immediate.

    On the machine that's crashing, The log looks the same but ends after the MANAGEMENT: >STATE:1499967384,ASSIGN_IP,,10.81.234.7,,, statement (I'm assuming that's where it's crashing, because if I stop the OpenVPN Interactive Service I get to the next entry (TEST ROUTES), then the route.exe ADD statements fail: Access is Denied. [status=5 if_index=11 or 30]

     

    thanks for your help with this!

    Ian

  • Ian,

    compare the computers that are having the issue with the computers that are working fine. SSl VPN creates a virtual NIC, maybe there is some imcompatibility with some NIC drivers/manifacture.

    Open a ticket with support and tell them the HW you are using.

    Regards

Reply
  • Ian,

    compare the computers that are having the issue with the computers that are working fine. SSl VPN creates a virtual NIC, maybe there is some imcompatibility with some NIC drivers/manifacture.

    Open a ticket with support and tell them the HW you are using.

    Regards

Children
  • Thanks for the help Luk,

     

    I think I figured it out: we had a SonicWall previously, and one of their VPN client versions didn't uninstall it's driver with the application (v4.7.3 if anyone is wondering), which was causing the conflict. It looked like it was a network interface card issue (I guess it was virtually), but the real correlation was the date-of-purchase, and thus what SonicWall client was current when the computer was loaded out.