Cannot Connect PPTP VPN



  • Hi,

    I've just updated our PfSense router to the very latest 2.0-BETA4 snapshot, and all is working fine, APART from we can no longer connect to any of our client sites using the standard MS PPTP VPN.

    The VPN starts to negotiate the connection, but always times out and generates a GRE block in the firewall logs.  I've run a packet capture on the WAN interface and get multiple repeats of the following until the VPN connection attempt times out.

    14:49:06.303090 IP MyMachineIP > RemoteServerIP: GREv1, call 20229, seq 6, length 37: LCP, Conf-Request (0x01), id 6, length 23

    Having looked through the posts, I'm guessing that the outbound GRE packet has bypassed the NAT and consequently on its way back then gets blocked as an unknown GRE connection attempt, when of course it is totally genuine.

    I've tried fricker, and that didn't work either.

    Anyone have any advice ?  I run an IT support company and we rely heavily on PPTP VPN's for remote support.  I know I could rebuild the box with 1.23, but it was working perfectly until I upgraded today - I'd even be happy to roll back to an earlier snapshot if thats possible ?

    Thanks

    Jake



  • Can you post or send to me tcpdump on LAN and WAN and also pfctl -vss ouptut?
    A quick fix for you is to add a rule on WAN to allow gre proto in.



  • Hi,

    Thanks for your asistance in this - can I PM you the logs, and if so how ?  Don't much fancy just posting my unredacted logs in public to be honest.

    Thanks,

    jake



  • Oh, forgot to mention - adding a rule for "GRE in from any to any" just seems to stop the error being flagged up in the firewall logs, but doesn't actually fix the problem, i.e. we still cant connect a PPTP VPN.

    Thanks

    Jake



  • You can send logs on
    eri at SPAM SPAM pfsense dot org

    For PPTP send me the logs but check your configs it should work the same.
    I committed a fix for allowing multiple GRE tunnels to the same ip and it should not affect anything apart having the need for the rule i mentioned.



  • 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



  • @safetynet:

    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 ?





  • will try it asap.
    Thanks Ermal.



  • Same issue here.
    Tried to use it with Win2k8 TMG.
    TMG's gateway is pfSense LAN IP (this is important! without this forwarding doesn't work)
    Seems it even don't try to connect, just refusing connection with CLOSED:SYN_SENT.
    Just ignoring firewall rules… or I have missed something in pfSense firewall?
    Check screenshots attached.

    EDIT: sorry for information missed: tested on pfSense-2.0-BETA4-20101116-1840-i386.iso
    EDIT: Thanks for fix for Ticket #989. Will try this as soon new snapshot will be available.










  • You do not need the gre allowance with latest snaphots.
    Your problem is that you do not need to specify the gateway in firewall rules.



  • Confirming that outgoing PPTP VPN now works w/o incoming GRE-rule - thanks :D



  • Confirming this too.

    Thanks



  • Confirming that PPTP limitations are gone for good :)

    Thanks!

    ermal: just curious - will there be an OpenBSD pf patch in the future?



  • You can try yourself.
    From my side i am done with OpenBSD folks doing politics.



  • nice reply Ermal  ;)



  • confirmed as well on 2.0-BETA4 (i386)
    built on Wed Nov 24 19:45:12 EST 2010

    well done guys, thanks so much for this


Log in to reply