VPN connection disconnects each time the line is heavily used

Hi, Paul, and welcome to the UTM Community!

What resources have you allocated the the VM for your UTM?  Do you get any hints from #1 in Rulz?  Please insert pictures of your Bandwidth Pools and Download Throttling rules.

Cheers - Bob

Hi Bob,

Thanks for your reply! (& sorry for my late feedback)

I have the following resources allocated:

2 x vCPU | 4 GB RAM | 40 GB HDD | 2x NIC Intel E1000

I also went through the Rulz page, kudos for that, very helpful & informative!

I couldn't find any irregularities in my UTM config with regards to the Rulz info.
But then again, I'm still in my (steep) learning curve, might've easily overlooked something ;)

In the meantime I deleted any throttling rules I created earlier as they didn't seem to have any effect at all.

Here the screenshot of my bandwidth pool: (mind this could be very much wrongly configured :)

When my Internet connection is not fully in use, there is no problem whatsoever, the VPN connection stays online & stable.
It's only when (scheduled) file transfers take place, the VPN connection will always disconnect some seconds after such a file transfer started.
I also tried limiting the incoming file transfer speed from 10 MB/s (= max capacity) to 8 MB/s, leaving roughly 2 MB/s for VPN and other traffic, but alas to no avail.

Since this never happened with the VPN connection on the TMG, I can only assume that the UTM VPN connection has a more
sensitive connection timeout setting, or is less robust & resilient in keeping the connection up, even when some drops might occur.

Hopefully there is a way to strengthen the UTM VPN connection, of find another underlying issue.

Thanks for your help!

Kind regards
Paul.

Yeah, it's tough to help with a QoS rule when the problem is that the pipe is totally full.  I don't know of any timeouts that might be changed for PPTP.  Can you post the lines from the PPTP log from the beginning of the download to the moment the VPN dies?

Cheers - Bob

Hi Bob,

Sure, hereby the PPTP logs from the latest disconnect:

-----

2016:06:16-11:12:02 utm pptpd[19294]: GRE: accepting packet #91979
2016:06:16-11:12:03 utm pptpd[19294]: GRE: accepting packet #91980
2016:06:16-11:12:03 utm pptpd[19294]: GRE: accepting packet #91981
2016:06:16-11:12:03 utm pppd-pptp[19295]: No response to 4 echo-requests
2016:06:16-11:12:03 utm pppd-pptp[19295]: Serial link appears to be disconnected.
2016:06:16-11:12:03 utm pppd-pptp[19295]: Connect time 171.6 minutes.
2016:06:16-11:12:03 utm pppd-pptp[19295]: Sent 12821709 bytes, received 4590356 bytes.
2016:06:16-11:12:03 utm pppd-pptp[19295]: Script /etc/ppp/ip-down started (pid 31665)
2016:06:16-11:12:03 utm pppd-pptp[19295]: MPPE disabled
2016:06:16-11:12:03 utm pppd-pptp[19295]: sent [LCP TermReq id=0x3 "MPPE disabled"]
2016:06:16-11:12:03 utm pppd-pptp[19295]: sent [LCP TermReq id=0x4 "MPPE disabled"]
2016:06:16-11:12:03 utm pptpd[19294]: GRE: accepting packet #91982
2016:06:16-11:12:03 utm pptpd[19294]: CTRL: Received PPTP Control Message (type: 15)
2016:06:16-11:12:03 utm pptpd[19294]: CTRL: Got a SET LINK INFO packet with standard ACCMs
2016:06:16-11:12:03 utm pppd-pptp[19295]: rcvd [LCP TermAck id=0x3 "MPPE disabled"]
2016:06:16-11:12:03 utm pppd-pptp[19295]: Connection terminated.
2016:06:16-11:12:03 utm pptpd[19294]: GRE: buffering packet #91984 (expecting #91983, lost or reordered)
2016:06:16-11:12:03 utm pptpd[19294]: GRE: buffering packet #91985 (expecting #91983, lost or reordered)
2016:06:16-11:12:03 utm pppd-pptp[19295]: Waiting for 1 child processes...
2016:06:16-11:12:03 utm pppd-pptp[19295]:   script /etc/ppp/ip-down, pid 31665
2016:06:16-11:12:03 utm pptpd[19294]: GRE: buffering packet #91986 (expecting #91983, lost or reordered)
2016:06:16-11:12:03 utm pppd-pptp[31665]: id="2202" severity="info" sys="SecureNet" sub="vpn" event="Connection terminated" username="paul" variant="pptp" srcip="Public-IP" virtual_ip="192.168.1.154"
2016:06:16-11:12:03 utm pppd-pptp[19295]: Script /etc/ppp/ip-down finished (pid 31665), status = 0x0
2016:06:16-11:12:03 utm pppd-pptp[19295]: DHCPC: adding option 0x35
2016:06:16-11:12:03 utm pppd-pptp[19295]: DHCPC: adding option 0x3d
2016:06:16-11:12:03 utm pppd-pptp[19295]: DHCPC: adding option 0x3c
2016:06:16-11:12:03 utm pppd-pptp[19295]: DHCPC: adding option 0x32
2016:06:16-11:12:03 utm pppd-pptp[19295]: DHCPC: adding option 0x36
2016:06:16-11:12:03 utm pppd-pptp[19295]: DHCPC: Sending release...
2016:06:16-11:12:03 utm pppd-pptp[19295]: DHCPC: entering none listen mode on *
2016:06:16-11:12:03 utm pppd-pptp[19295]: Exit.
2016:06:16-11:12:03 utm pptpd[19294]: GRE: read(fd=6,buffer=805a540,len=8196) from PTY failed: status = -1 error = Input/output error, usually caused by unexpected termination of pppd, check option syntax and pppd logs
2016:06:16-11:12:03 utm pptpd[19294]: CTRL: PTY read or GRE write failed (pty,gre)=(6,7)
2016:06:16-11:12:03 utm pptpd[19294]: CTRL: Reaping child PPP[19295]
2016:06:16-11:12:03 utm pptpd[19294]: CTRL: Client Public-IP control connection finished
2016:06:16-11:12:03 utm pptpd[19294]: CTRL: Exiting now
2016:06:16-11:12:03 utm pptpd[22168]: MGR: Reaped child 19294

-----

Cheers, Paul.

Paul, try changing the virtual NICs to VMXNET3 instead of Intel 1000 - that might fix this (that's a WAG).  Also, unless you've only a handful of users, The recommended minimum disk size really is 60GB.

Cheers - Bob

Paul, try changing the virtual NICs to VMXNET3 instead of Intel 1000 - that might fix this (that's a WAG).  Also, unless you've only a handful of users, The recommended minimum disk size really is 60GB.

Cheers - Bob

Hi Bob,

Thanks for the tip, I've now changed both NIC's from E1000 to VMXNET3.

So far no luck with the disconnects, they're still happening when the line saturates.

I've got a very modest setup behind the UTM, only 5 users give or take.

Currently 40 GB HDD seems to be sufficient, as far as I can tell from the graphs/stats that is.

If needed, I guess I can extend the HDD & partitions?

Cheers, Paul.

It sounds like your sizing is good.

The problem appears to be 2016:06:16-11:12:03 utm pppd-pptp[19295]: No response to 4 echo-requests.  What happens if you do the following as root at the command line?

cc set packetfilter timeouts ip_conntrack_icmp_timeout 60

If it works, see how low you can go while still maintaining the connection.  The standard is 30, so set it back to that if this has no effect.

If you still have the problem, consider using the SSL VPN instead.  It's my preferred remote access method.  If you have an iPhone or an Android, get the free OpenVPN app.

Cheers - Bob

Hi bob,

Thanks for the tip!  I tried with several settings (30-60-120-...) but alas the same behaviour.

It would be nice if I could alter the amount of echo request it takes for a disconnect to occur.
-> No response to 4 echo-requests.  (sure would want to try and set this to a higher number if possible)

I already tried setting up a L2TP/IPsec connection in conjunction with the built-in client VPN capabilities of Windows, no luck so far. (also followed a guide)
(I would very much like to use the built-in VPN capabilities of Windows, and thus not installing 3rd party VPN apps, as they sometimes can cause issues)

Currently I'm using a WatchGuard XTM33 connecting to VDSL2 via PPPoE, then NAT'ing to the UTM and then NAT'ing to the internal LAN.
Internet -> VDSL2 modem bridged -> (PPPoE external IP) WatchGuard -> (10.0.1.x) external UTM -> (192.168.1.x) internal UTM
Perhaps the L2TP/IPsec does not like the double NAT'ing, I'll try building the VPN connection from the 10.0.1.x subnet, straight on the UTM's external NIC.

I'm going to try SSL VPN next, not sure if I need 3rd party client VPN tools for that, I sure hope not :)

Cheers,
Paul.

Hi bob,

I've now set up the SSL-VPN in the UTM which was a breeze sort of speak :)
Certainly compared to the L2TP/IPsec dread which didn't even work in the end.

Too bad the built-in Windows VPN client cannot connect to the UTM's SSL-VPN.
I had to install the Sophos VPN client, which seems quite lightweight but stable.

So far the SSL-VPN connection I started this morning, is still going strong & rocksolid.
No disconnects yet, whilst several FTP transfers have taken place, maxing out the line.
This does look promising :)

I have one question though, why isn't it possible to get an internal IP address, even via
the local DHCP server, which worked perfectly with the PPTP VPN connection.
Now I get a 10.x.x.x IP address, internal LAN IP's are pingable & reachable, only one
thing, being that the webinterface of the webcam now crashes with a plugin error.
This does not happen with the PPTP connection, must be something network related.

It is not possible to add the local LAN network range as a VPN address pool if I'm not mistaken.
When I tried this, some conflict arose and the UTM wasn't even reachable any more via the LAN interface.

Cheers,
Paul.

You are correct, Paul - it's only with PPTP and L2TP/IPsec that you can have clients assigned an IP in the Internal network by DHCP.  Trying to do that with the VPN Pool objects will result in routing conflicts.

Cheers - Bob

Hi Bob,

Yes indeed, serious routing issues :) as in the UTM's private LAN port not accessible any more.
It would be a nice protection/security feature for the UTM to warn & block any attempt to enter the same LAN subnet as a VPN pool.

So far, not had any disconnects whatsoever since I've been using SSL-VPN, very happy about it I must say!

Thanks for all your help & tips! :)

cheers,
Paul.