PP2T VPN client weirdness
-
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?
-
haha.. good point. Mine is rather quick also. Who knows then.
-
Wouldn't it be easier to have it automatically create a Dead Peer Detection routine just like IPSec to keep it alive?
Darkk
-
I think the problem is that the state table gets messed up somehow and the reply packets do not make it back to the NAT-ed host.
-
Any news on this?