PPTP WAN (still) issue (MTU and fragmentation) going from 1.2.3 to 2.0RC3
-
This is the output of /tmp/rules.debug
It is set to factory defaults, just to try.#System aliases loopback = "{ lo0 }" WAN = "{ pptp1 }" LAN = "{ vr0 }" #SSH Lockout Table table <sshlockout> persist table <webconfiguratorlockout> persist #pfSnortSam tables table <snort2c> table <virusprot> # User Aliases # Gateways GWWAN = " route-to ( pptp1 195.190.242.11 ) " set loginterface vr0 set optimization normal set limit states 48000 set limit src-nodes 48000 set skip on pfsync0 scrub in on $WAN all fragment reassemble scrub in on $LAN all fragment reassemble nat-anchor "natearly/*" nat-anchor "natrules/*" # Outbound NAT rules # Subnets to NAT tonatsubnets = "{ 192.168.1.0/24 127.0.0.0/8 }" nat on $WAN from $tonatsubnets port 500 to any port 500 -> 213.84.84.84/32 port 500 nat on $WAN from $tonatsubnets to any -> 213.84.84.84/32 port 1024:65535 # Load balancing anchor rdr-anchor "relayd/*" # TFTP proxy rdr-anchor "tftp-proxy/*" table <direct_networks> { 213.84.84.84/32 192.168.1.0/24 } # UPnPd rdr anchor rdr-anchor "miniupnpd" anchor "relayd/*" #--------------------------------------------------------------------------- # default deny rules #--------------------------------------------------------------------------- block in log all label "Default deny rule" block out log all label "Default deny rule" # We use the mighty pf, we cannot be fooled. block quick proto { tcp, udp } from any port = 0 to any block quick proto { tcp, udp } from any to any port = 0 # Block all IPv6 block in quick inet6 all block out quick inet6 all # pfSnortSam block quick from <snort2c> to any label "Block snort2c hosts" block quick from any to <snort2c> label "Block snort2c hosts" block quick from <pfsnortsamout> to any label "Block pfSnortSamOut hosts" block quick from any to <pfsnortsamin> label "Block pfSnortSamIn hosts" # SSH lockout block in log quick proto tcp from <sshlockout> to any port 22 label "sshlockout" # webConfigurator lockout block in log quick proto tcp from <webconfiguratorlockout> to any port 443 label "webConfiguratorlockout" block in quick from <virusprot> to any label "virusprot overload table" antispoof for pptp1 # allow PPTP client pass in on $WAN proto tcp from any to any port = 1723 flags S/SA modulate state label "allow PPTP client on WAN" pass in on $WAN proto gre from any to any keep state label "allow PPTP client on WAN" antispoof for vr0 # loopback pass in on $loopback all label "pass loopback" pass out on $loopback all label "pass loopback" # let out anything from the firewall host itself and decrypted IPsec traffic pass out all keep state allow-opts label "let out anything from firewall host itself" pass out route-to ( pptp1 195.190.242.11 ) from 213.84.84.84 to !213.84.84.84/32 keep state allow-opts label "let out anything from firewall host itself" # make sure the user cannot lock himself out of the webConfigurator or SSH pass in quick on vr0 proto tcp from any to (vr0) port { 80 443 22 } keep state label "anti-lockout rule" # User-defined rules follow anchor "userrules/*" pass in quick on $WAN reply-to ( pptp1 195.190.242.11 ) from any to any keep state label "USER_RULE" pass in quick on $LAN from 192.168.1.0/24 to any keep state label "USER_RULE: Default allow LAN to any rule" # VPN Rules anchor "tftp-proxy/*"</virusprot></webconfiguratorlockout></sshlockout></pfsnortsamin></pfsnortsamout></snort2c></snort2c></direct_networks></virusprot></snort2c></webconfiguratorlockout></sshlockout>This is /tmp.rules.debug on the working 1.2.3 system (relevant part for as far i know)
# System Aliases loopback = "{ lo0 }" lan = "{ vr0 }" ng0 = "{ vr1 ng0 }" wan = "{ vr1 ng0 }" enc0 = "{ enc0 }" pptp = "{ ng1 ng2 ng3 ng4 ng5 ng6 ng7 ng8 ng9 ng10 ng11 ng12 ng13 ng14 ng15 ng16 }" WLAN = "{ vr2 }" # User Aliases set loginterface vr1 set loginterface vr0 set loginterface vr2 set optimization normal set skip on pfsync0 scrub all random-id fragment reassemble nat-anchor "pftpx/*" nat-anchor "natearly/*" nat-anchor "natrules/*" # FTP proxy rdr-anchor "pftpx/*" # Outbound NAT rules nat on $ng0 from 192.168.1.0/24 port 500 to any port 500 -> (ng0) port 500 nat on $ng0 from 192.168.1.0/24 port 5060 to any port 5060 -> (ng0) port 5060 nat on $ng0 from 192.168.1.0/24 to any -> (ng0) port 1024:65535 nat on $ng0 from 192.168.1.208/28 port 500 to any port 500 -> (ng0) port 500 nat on $ng0 from 192.168.1.208/28 port 5060 to any port 5060 -> (ng0) port 5060 nat on $ng0 from 192.168.1.208/28 to any -> (ng0) port 1024:65535 #SSH Lockout Table table <sshlockout>persist # Load balancing anchor - slbd updates rdr-anchor "slb" # FTP Proxy/helper table <vpns>{ } no rdr on vr0 proto tcp from any to <vpns>port 21 rdr on vr0 proto tcp from any to any port 21 -> 127.0.0.1 port 8021 no rdr on vr2 proto tcp from any to <vpns>port 21 rdr on vr2 proto tcp from any to any port 21 -> 127.0.0.1 port 8022 # NAT Inbound Redirects # IMSpector rdr anchor rdr-anchor "imspector" # UPnPd rdr anchor rdr-anchor "miniupnpd" anchor "ftpsesame/*" anchor "firewallrules" # We use the mighty pf, we cannot be fooled. block quick proto { tcp, udp } from any port = 0 to any block quick proto { tcp, udp } from any to any port = 0 # snort2c table <snort2c>persist block quick from <snort2c>to any label "Block snort2c hosts" block quick from any to <snort2c>label "Block snort2c hosts" # Block all IPv6 block in quick inet6 all block out quick inet6 all # loopback anchor "loopback" pass in quick on $loopback all label "pass loopback" pass out quick on $loopback all label "pass loopback" # package manager early specific hook anchor "packageearly" # carp anchor "carp" # permit wan interface to ping out (ping_hosts.sh) pass quick proto icmp from 213.84.84.84 to any keep state # NAT Reflection rules # allow PPTP client anchor "pptpclient" pass in quick on $wan proto gre from any to any modulate state label "allow PPTP client" pass in quick on $wan proto gre from any to any modulate state label "allow PPTP client" pass in quick on $wan proto tcp from any port = 1723 to any flags S/SA modulate state label "allow PPTP client" pass in quick on $wan proto tcp from any to any port = 1723 flags S/SA modulate state label "allow PPTP client" block in log quick on $wan proto udp from any port = 67 to 192.168.1.0/24 port = 68 label "block dhcp client out wan" # LAN/OPT spoof check (needs to be after DHCP because of broadcast addresses) antispoof for vr0 antispoof for vr2 anchor "spoofing" # Support for allow limiting of TCP connections by establishment rate anchor "limitingesr" table <virusprot>block in quick from <virusprot>to any label "virusprot overload table" # block bogon networks # http://www.cymru.com/Documents/bogon-bn-nonagg.txt anchor "wanbogons" table <bogons>persist file "/etc/bogons" block in log quick on $wan from <bogons>to any label "block bogon networks from wan" # let out anything from the firewall host itself and decrypted IPsec traffic pass out quick on $lan proto icmp keep state label "let out anything from firewall host itself" pass out quick on $wan proto icmp keep state label "let out anything from firewall host itself" # tcp.closed 5 is a workaround for load balancing, squid and a few other issues. # ticket (FEN-857512) in centipede tracker. pass out quick on ng0 all keep state ( tcp.closed 5 ) label "let out anything from firewall host itself" # pass traffic from firewall -> out anchor "firewallout" pass out quick on vr1 all keep state label "let out anything from firewall host itself" pass out quick on vr0 all keep state label "let out anything from firewall host itself" pass out quick on vr2 all keep state label "let out anything from firewall host itself" pass out quick on $pptp all keep state label "let out anything from firewall host itself pptp" pass out quick on $enc0 keep state label "IPSEC internal host to host" # let out anything from the firewall host itself and decrypted IPsec traffic pass out quick on vr2 proto icmp keep state ( tcp.closed 5 ) label "let out anything from firewall host itself" pass out quick on $WLAN all keep state ( tcp.closed 5 ) label "let out anything from firewall host itself" # make sure the user cannot lock himself out of the webGUI or SSH anchor "anti-lockout" pass in quick on vr0 from any to 192.168.1.250 keep state label "anti-lockout web rule" # PPTPd rules anchor "pptp" pass in quick on $wan proto gre from any to 213.84.84.84 keep state label "allow gre pptpd" pass in quick on $wan proto tcp from any to 213.84.84.84 port = 1723 modulate state label "allow pptpd 213.84.84.186" # SSH lockout block in log quick proto tcp from <sshlockout>to any port 22 label "sshlockout" anchor "ftpproxy" anchor "pftpx/*" # IMSpector anchor "imspector" # uPnPd anchor "miniupnpd" #--------------------------------------------------------------------------- # default deny rules #--------------------------------------------------------------------------- block in log quick all label "Default deny rule" block out log quick all label "Default deny rule"</sshlockout></bogons></bogons></virusprot></virusprot></snort2c></snort2c></snort2c></vpns></vpns></vpns></sshlockout>In both files i see the GRE protocol pass on the interface vr1. port 1723 (it is an soekriss 5501 board)
In my logs on the 2.0 i see that they are dropped from the vr1 interface.The vr1 interface is not shown in my rules.debug file on the 2.0 machine but is on the 1.2.3 machine
On the working machine i have wan = "{ vr1 nr0}"
On the 2.0 i only have wan = "{ pptp0 }"So the pass rules as far as i understand for the GRE protocol do not get set for the vr1 interface where i see all the drops in my log file.
# allow PPTP client pass in on $WAN proto tcp from any to any port = 1723 flags S/SA modulate state label "allow PPTP client on WAN" pass in on $WAN proto gre from any to any keep state label "allow PPTP client on WAN"Could it be that i need to set wan = "{ vr1 pptp1 }" ?
regards
Johan Hendriks -
I have exactly the same problem with 2.0RC3. It seems that MSS Clamping is somehow broken with PPTP in 2.0.
-
Well i got it working, but it wil not survive a reboot.
what i did was the following
I did go to diagnostics, then edit file.
I opened /tmp/rules.debug
i put in the actual interface between the brackets of the wan interface.
wan = { pptp1 } and i changed it to wan = { vr1 pptp1}
Then i did go to diagnostics and then command
In the command box i did do pfctl -f /tmp/rules.debugThen after hitting F5 in the browser which could not load any page, it all started to work, the pages were loaded.
To make sure it was this, i opened the traffic box and started to download a iso image from an ftp server, and the graph did flew up.So the reason, it is not working in my case is that the vr1 interface does drop the GRE packages.
And the pf rules actually do let them pass, but the interface is not added to the wan.regards,
Johan -
Works, thanks!
edit:
I would like to make this survive a reboot with this script:
sed 's/{ pptp0 }/{ vr1 pptp0 }/g' /tmp/rules.debug > /tmp/rules.debug.new mv /tmp/rules.debug.new /tmp/rules.debug pfctl -f /tmp/rules.debugI put it under /usr/local/etc/rc.d/fix_pptp like suggested in this thread but it is not executed at startup. Also pfsense does not automatically establish the PPTP-connection at startup. (I don't have Dial-On-Demand enabled)
Regards,
Michael
edit2:
Due to the connection being to unstable (I even had the above script in a cronjob every minute) I have downgraded to 1.2.3.
-
Hi,
Noticed 2.0-final was released yesterday so I couldn't resist trying it out to see if the pptp issue was resolved. Did a clean install just now but alas, the situation remains unchanged.
After that, decided to give Sylhouette's fix a try (for me it was adding em1 to pptp0) and this fixed the problem for me on the 2.0-final release!
Can't say anything yet about stability; I'll leave this running for a while and if it's stable, I'll try to get it reboot-proof.
rgds,
A. -
I think a lot of people get bitten by this.
Every firewall solution i tryed, work with the pptp solution.
monowall, the older pfsense, smoothwall, and sonicwall are the once i tried.
All without problem.i need it to survive a reboot, we have a very poor power grid on one location, and power fails sometimes for more than 4 to 5 hours.
And this happens more than once per month.Well we should see what we can do.
For now i leave these boxes at 1.2.3 because it works and works well.regards.
Johan Hendriks -
Hi,
Agree that it's a bit peculiar that something like pptp would be broken. Maybe pptp isn't all that popular anymore, don't know.
Your fix remained stable since I applied it. It's most probably not that hard to make it reboot proof by using some <shellcmd>statements in the config.xml. However, I guess (but haven't verified) that pfctl gets called whenever the ruleset is changed which would basically undo the commands issued from the config.xml (and break the pptp again)
The only reboot / filter-reload proof way to handle this seems to be to modify one (or multiple) scripts in the /etc (or /etc/rc.d) directories. Wouldn't want to do that on a production system since I don't know enough about the details of the inner workings of pfsense to feel confident that such hacking wouldn't result in undesirable behavior..
So, I'm (unfortunately) staying with 1.2.3. as well. Hope somebody can pick this issue up and raise a bug against it so maybe it can get resolved in an upcoming release..
b.r.
A.</shellcmd> -
Well i made it survive a reboot also, but this is an UGLY way.
go to diagnostics then edit file
open the file/etc/inc/filter.incthen around line 2221 you find the following.
# allow PPTP client pass in on \${$oc['descr']} proto tcp from any to any port = 1723 flags S/SA modulate state label "allow PPTP client on {$oc['descr']}" pass in on \${$oc['descr']} proto gre from any to any keep state label "allow PPTP client on {$oc['descr']}"In my case my actual WAN interface is vr1 so i put a allow rule there on vr1.
Then it shows the following.#allow PPTP client pass in on \${$oc['descr']} proto tcp from any to any port = 1723 flags S/SA modulate state label "allow PPTP client on {$oc['descr']}" pass in on \${$oc['descr']} proto gre from any to any keep state label "allow PPTP client on {$oc['descr']}" pass in on vr1 proto gre from any to any keep state label "allow PPTP client on {$oc['descr']}"This way it stays active after a reboot.
NOTE THIS IS NOT THE WAY TO DO IT..But it works this way ….
And it seems we are the only one who have this.
On the other hand, it is saver than to set the wan value to vr1 and pptp0, because this way only GRE is allowed and in the rest of the script wan is just pptp0 like before.It does not survive an upgrade however. :D
Gr
Johan Hendriks -
Does anyone know if the developers are working on this issue or even are aware of it? Should someone (me?) create a ticket in redmine?
-
I opened a thread on the mailling list.
When the 2.0 anouncement came, i repleyed on that by asking if this was resolved.
The following anwer came
That's not a general issue, and haven't heard that from anyone else,
not sure what you're seeing.I replied on that by explaining what i saw and how in my case i got that fixed.
I also reffered to this thread on the forum.Then to my surprise i almost got a ban from the mailing list, this was the answer i got on my relpy.
Stop here, you're hijacking a thread. Bump your own thread if you want
to continue.I replied again with a sorry that it was not my intention to hijajack a thread. ( i really was not )
And that i already had a threat on the mailling list about this issue and gave the link to the thread on the mailling list.Never heard anything after that.
I did not send an e-mail to the mailling list after that so maybe i am already banned :(, i hope not, because i like to help out sometimes, and i learn a lot about PFSense through the mailling list.So i really do not know the status.
regards,
Johan Hendriks -
Hi,
Opening a ticket is probably the best way forward since several people clearly have the same reproducible problem with PPTP (some might call that a bug ;)) . I don't know how to get from a discussion on the forum to an actual ticket in pfsense's bugtracker - mseiwald, if you are capable of raising a ticket, yes please!
Probably a good idea to include Sylhouette's two fixes in the bug description as well.
rgds,
A. -
Hi all,
Just noticed 2.0.1 is out! Before I give it a try, I was wondering if anyone knows if the PPTP WAN problem that existed since 2.0RC1 has been properly fixed yet. Doesn't seem to be (explicitly) in the list of changes in the release notes but who knows..
br.
A. -
I'm seeing an MTU issue after upgrading from 1.2.3 to 2.0. I 'fixed' this by editing
/var/etc/pptp-vpn/mpd.conf
and adding:
set link mtu 1396
Then, killing the mpd process and restarting it:
/usr/local/sbin/mpd4 -b -d /var/etc/pptp-vpn -p /var/run/pptp-vpn.pid -s pptps pptps
That's not a pfSense 'solution' but perhaps others here could try it to see if our problems are the same?
This wasn't necessary before, so I'm wondering if defaults are different, path MTU discovery is somehow broken, etc. BTW, I read that XP's pptp client requires 1396, so that's what I set for a compatibility floor.
