Cannot Connect PPTP VPN
-
Just to bump, and to say that in 2.0-BETA4 snapshot built on Mon Oct 25 02:28:25 EDT 2010, the problem still exists - I've factory defaulted the box and just set up the WAN connection, leaving all NAT & Firewall rules blank, then tried to connect a PPTP VPN from my windows 7 PC to a remote server and get exactly the same error, and see the same inbound GRE block in the firewall logs.
I then added just a firewall rule to allow GRE from all to all, and now don't see the error in the logs, but still can't connect the PPTP VPN.
Thanks
Jake
Frankly, PPTP in 2.0 has some issues (which is why we started using openvpn which is much better BTW)…
We also find we have to use ip aliases in pfsense for the PPTP host ip's in order to pass any traffic due to an unaddressed or unfixable (I don't know which) arp issue.
-
We are also having the PPTP-Issue since the update a few days ago :(
As we heavily rely on PPTP-Connections, we are currently a little bit thrown out of our systems :-/
Is there a fix on the way? :-)
Thanks and best regards,
Christian
-
I'm also having the same issue which start after the upgrade on 10/24. The GRE rule fix (stated above) doesn't help. Would it be helpful if I provided a tcpdump?
-
Same issue here.
I started playing around with OpenVPN the other day - at least I went through the wizard and set up the server, got a little confused when having to set up users, but I think I got it. I will set up a client tomorrow and see how things. It's interesting to me how OpenVPN states in their Community Software Overview "Starting with the fundamental premise that complexity is the enemy of security…" - it feels to me like setting up the Open VPN stuff is far more complex than our old PPTP stuff. Then again, this is only my second foray into VPN, so perhaps more complex in this case means batter? I will update tomorrow when I have played with a client setup...
Aaron
-
Better yet, does anyone know when this function was broken? I can't remember which version was the first 2.0 I upgraded to (by upgrade I mean a fresh install from 1.2.3 and a config build from scratch), but then I upgraded the other day to the version from Mon Oct 25 02:28:25 EDT 2010. I have written down which version I first had, but it's at the office, and it was also broken there - from my NMS logs I downloaded on the morning of Oct. 19. Does anyone know what they upgraded from when the PPTP broke? Might help track the issue…
My upgrade was to get support for an Intel quad GB NIC (igb0-3), 1.2.3 wouldn't recognize it.
Aaron
-
I'm not sure if this helps, but I rolled back to the previous release and my PPTP client passthru is now fully operational. Here's the last known working release that worked for me:
Current version: 2.0-BETA4 - Built On: Wed Oct 20 06:03:46 EDT 2010
-
haha Nope, I don't think that helps - my original version that was broken was pfSense-2.0-BETA4-20101018-1506. I will try to move to your working version and see what happens…
-
Downgraded to the same build you mention, and my clients can connect now, but can't seem to pass any traffic.
I finished messing around the OpenVPN, and while the setup of the server seems a little daunting, the client installs are super easy when you use the Client Export package. Now I need to figure out how to add connections (servers) to the client without having to run the whole OpenVPN installer from the new server…
-
same here
sometimes i get bad hdr on the 1723 connection sometimes not but it never plug
00:00:00.040958 rule 46/0(match): pass in on rl1: 1.2.3.4.53172 > 4.3.2.1.1723: tcp 32 [bad hdr length 0 - too short, < 20]
00:00:00.258970 rule 46/0(match): pass in on rl1: 1.2.3.4 > 4.3.2.1: GREv1, call 1139, seq 0, proto PPP (0x880b), length 37: [|ppp]< -
Hi,
I have the same bug, but in my case I managed to solve it.
I have a setup at home, where only one machine (Win7) has to connect via PPTP VPN.
So I did port forwarding, where anything that goes to PPTP port (TCP/1723) and GRE - goes to the Win7 machine. Firewall rules were added automatically upon the creation of those.Also, I had to enable the built-in Win7 firewall rules: allow GRE-In and allow PPTP-In.
The VPN works.
Before that I had a 1.2.2 version and everything worked fine. All these steps are new.Maybe this will lead you to the the solution.
P.S. I'm on the October 29-th snapshot.
-
Great workaround, thanks :D :D :D
I just had to add the two rules inside pfsense, didn't have to do anything on my Win7-Client…
It works now :)
Hopefully the bug will be resolved soon, then I can remove the rules again...
Thanks and best regards,
Chris
-
Hi,
thanks for the info and the suggested workaround, not gonna work for me though as we have multiple PC's initiating PPTP connections to different PPTP servers throughout the day.
Before anyone says anything about the known bug with multiple connections to the same PPTP server not working, this IS NOT the same issue - we can't connect a single client to an external PPTP server, never mind multiple clients to the same one !!
Think I'll try rolling back to see if that does the trick.
Thanks
Jake
-
Updated (from amd64 Oct 28th build to Nov 2nd build) and also (still) experiencing problems connecting to remote PPTP-servers (pfSense PPTP-server disabled) - adding a NAT-rule to route incoming GRE to the IP I try to connect from works for a temp. solution…
Would prefer something more friendly though ;) especially as I occasionally switch which computer I want to connect from...
-
What is the status of this very annoying problem ?
-
yes this is incredibly frustrating. Any update on a fix, had a great, stable experience with previous builds but being able to make an outbound PPTP connection is critical for us so very tempted to rollback to 1.2.x until 2.x is ready for the time being.
currently using 2.0-BETA4 (i386) built on Mon Nov 1 01:27:31 EDT 2010
was tempted to update to latest but saw people are still having issues
-
couldn't actually see this reported in redmine.
have reported now, http://redmine.pfsense.org/issues/989
-
Is there a known workarround (like a kernel parameter)?
Do you know where does the bug comes from ? pfSense code or kernel update issue ?Thanks
-
Other people have reported success if they manually forward 1723/tcp and GRE through to an internal IP and then make a connection outbound from the machine with that address. It appears to be the traffic coming back in without an explicit NAT rule that is the issue, so you can't just plug say a laptop in, get an IP via DHCP and establish a PPTP VPN.
I was hoping to dig further but in the middle of a big project at the moment, will try add some beef to the PR at somepoint.
-
Ok so it seems to be a state tracking problem ?
When you watch the logs during a connection attempt (tcpdump -i pflog0 -ttt -n) you can see GRE responses from the outside server being blocked by pf. -
No news neither a clue about this issue ?