PP2T VPN client weirdness
-
Sorry the title should have been PPTP
-
I can add that if I have for instance an RDP session open to a machine in the VPN's subnet, the connection stays alive. The moment I do not send any traffic for about 1-2 minutes the connection dies. This happens from within a Windows 7 VM as well as from my Mac which are both on the LAN, and to different VPN servers.
-
You need keep-alive for the session activated or increase the state timeout for the PPTP port otherwise the GRE sessions will be dropped.
-
I assume with keep alives you refer to lcp-echo-interval and lcp-echo-failure? I do not have access to that on Windows and Mac OS X as far as I know. And where do I change the state timeout of the PPTP port? On the server?
Just asking since pfSense from about 6 months ago worked just fine with these PPTP servers, and since I manage some of them I know they have not changed. So too did my local configuration not change. I could leave VPN connected all night without issue.
-
If you want you can allow gre any to any as it was done before in firewall rules.
-
Both on WAN and LAN interfaces?
-
Yes. Or you can tight them down if you know the PPTP vpn ip(s).
-
I now have an allow any to any on GRE on WAN and LAN - still same thing that happens. Connection is made just fine, leave it for 1 minute then it just sits there, sending packets but never receiving.
I do see this in my firewall log - not sure if it is related to VPN traffic though:
[Blocked] Dec 9 11:05:10 WAN 205.200.61.10:25749 96.51.181.89:26237 UDP
205.200.61.10 is the VPN server (remote), and 96.51.181.89 is the WAN IP on pfSense.
-
You should have an option on the client side to enable lcp-echo's
and those blocks are udp protocol. -
I have only ever seen lcp-echo's as configurable in Linux / BSD Unix. Never in Mac OS X or Windows. Any pointers?
Also why would it have worked perfectly with the pfSense beta from 6 months ago?
-
PS: A Cisco IPSec VPN connection works perfectly - stays online for hours.
-
Under linux I have configured a 30 second lcp echo request, the VPN still dies after a minute or two if I do not actively transfer data.
-
I'm seeing the same thing here on my end. If I leave it without sending packets the firewall starts blocking GRE packets:
[blocked] Dec 11 08:08:30 WAN A.A.A.A B.B.B.B GRE
Where A is the remote VPN server IP, and B is the pfsense box IP.It ONLY starts blocking these GRE packets if it sits for a little while without sending packets. As long as pfsense keeps sending packets then it'll never start blocking GRE. However, the game is over once it starts.
If I add a rule to allow all GRE traffic on the WAN interface then those errors are surpressed. The firewall logs don't show anything being blocked. However, the problem still exists. All VPN traffic stops and I must disconnect and reconnect to fix it.
I'm running 2.0-BETA4 (i386) built on Tue Dec 7 06:58:02 EST 2010
-
I agree with yaw - exactly the same behaviour. Furthermore, if I replace pfSense with my DLink WiFi router, the problem goes away and my PPTP connections stay alive without needing any keep alive traffic.
-
Yep.. something odd going on here. I never had this problem with version 1.2.3
-
Also not with pfSense 2.0 BETA3 from June this year I think.
-
Yes I am seeing this exact same issue with the beta snapshots as of late. I tried a few things and had to revert back to the 1.2.3 release until it gets sorted out. This will be a problem for folks who PfSense at home offices and corporations.
So any ideas would be greately apprecaitedl.
Darkk
-
Found this: http://forum.pfsense.org/index.php/topic,29427.0.html, and tried adding the two NAT rules for TCP/1732 and GRE. What do you know - now it works. But I am confused - I thought this was fixed already? Secondly, obviously the NAT rules are only a temporary solution as I have multiple clients needing PPTP access behind the firewall.
(I say it worked because I managed 17 minutes and counting of idle PPTP traffic without being disconnected).
-
Yeah.. I have multiple clients here also.. not going to work.
I wonder if the fix always had this problem. I bet nobody let their connection sit idle long enough to test.
-
Mine will timeout like that within 45 seconds….
Grabbing a coffee?