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

VPN Split Tunnel traffic Issues

Hi all-

Hoping for some help with an ASG320 running UTM9 9.3x software. Recent setup, running VPN remote access PPTP in a windows environment. 

The current setup is using the UTM9 as a firewall/network protection. VPN currently works, but I cannot get split tunnel traffic to work correctly. When connected to the VPN, in a non-split tunnel environment, I get a default gateway on the VPN connection of 0.0.0.0 and everything seems to work (RDC, local domain DNS resolution before reaching external - DNS is being handled by a windows DNS server). When I run split, I'm not getting assigned a default gateway at all on the VPN connection, and cannot access network (VPN resources). Currently, I have the UTM9 pointing DNS to my DNS server, then to Google as a secondary (even though my DNS server reaches to Google for DNS if internal cannot be resolved). 

The only reason I point to the UTM9 first is that this identical setup worked prior to being migrated to a new site with the UTM9 as a firewall device. Is there a default gateway setting I'm missing somewhere?

 

Cheers,



This thread was automatically locked due to age.
Parents Reply Children
  • Masked is simply restricting the company name from public view in this particular document. 

     

    When connecting from home or a public hotspot and configuring the client in "full tunnel" - I have access to all VPN resources, everything works as it should (for all intent and purpose of this discussion). 

    When connecting on a split tunnel configuration on the client, I am still assigned the 192.168.6.2 IP address, but cannot talk to, ping, access, telnet, you name it, anything on the VPN resources, however internet does go out locally and not through the tunnel. 

    I'm sorry the picture isn't clear, and I appreciate the help. This isn't what I do for a day job and am just scraping by to make this all work.

  • Try a test from outside with a split tunnel, noting the assigned IP and the exact time of the test.  Connect to WebAdmin, Search the Firewall log file for your IP and show us a line or two from your test where the ping was blocked.

    Cheers - Bob

  • I'll do that in a bit once I'm off site. Meanwhile - food for thought- , I think when I tried this in the past, the dropped ping was not showing up in the firewall logs, however. Regardless, I'll try again for the sake of testing. IIRC, it was a routing issue of the client not knowing where to find the 192.168.6.1, or anything on the VPN side. Sorry if that makes no sense, I'll post test results shortly. Thanks again.

  • If it is not a firewall block, then show us the section of the PPTP log with the startup of your connection.

    Cheers - Bob

  • 2017:06:05-13:34:28 sophos pppd-pptp[27038]: Starting negotiation on /dev/pts/0
    2017:06:05-13:34:28 sophos pptpd[27037]: GRE: Bad checksum from pppd.
    2017:06:05-13:34:28 sophos pptpd[27037]: CTRL: Ignored a SET LINK INFO packet with real ACCMs!
    2017:06:05-13:34:28 sophos pppd-pptp[27038]: rc_map2id: can't find tty /dev/ in map database
    2017:06:05-13:34:28 sophos pppd-pptp[27038]: Using interface ppp0
    2017:06:05-13:34:28 sophos pppd-pptp[27038]: MPPE 128-bit stateless compression enabled
    2017:06:05-13:34:30 sophos pppd-pptp[27038]: Cannot determine ethernet address for proxy ARP
    2017:06:05-13:34:30 sophos pppd-pptp[27038]: local IP address 192.168.6.1
    2017:06:05-13:34:30 sophos pppd-pptp[27038]: remote IP address 192.168.6.2
    2017:06:05-13:34:31 sophos pppd-pptp[27041]: id="2201" severity="info" sys="SecureNet" sub="vpn" event="Connection started" username="domain.com\user" variant="pptp" srcip="[public.ip.adr.here]" virtual_ip="192.168.6.2"

     

    That's the logs for the connection (I've masked the domain, public IP, and usernames). 

     

    Confirmed the firewall is not blocking any packets from the 192.168.6.x into the LAN (from what I can tell). 

  • I don't often use PPTP and don't configure it for my clients.  I remember now that the only solution is to make a permanent route in the PC dialing into the UTM.

    This is another reason that I prefer SSL VPN.  There are free clients for Mac, Windows, iOS and Android.  Control over the traffic is determined by the UTM, not the client.  Configuring with UDP protocol makes the tunnel about as fast as L2TP/IPsec.  Using certificates instead of pre-shared keys makes the tunnel more secure than even 128-bit encryption for PPTP.  Etc.

    Cheers - Bob