PPTP WAN (still) issue (MTU and fragmentation) going from 1.2.3 to 2.0RC3

mseiwald

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.debug

I 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.

doctor strangelove

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.

Sylhouette

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

doctor strangelove

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>

Sylhouette

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.inc

then 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

mseiwald

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?

Sylhouette

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

doctor strangelove

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.

doctor strangelove

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.

bill_mcgonigle

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.