Rule for PPTP applies for external IF as well
-
Hi guys,
just tested out PPTP yesterday, 'cause I needed it at work. Today it occured, that I typed in the dyndns adress of pfsense and to my surprise the htaccess dialogue popped up (by accessing it via the internet!)! D'oh! Thought, that some weird rule I wrote did this but no, there was none.
Than I debugged the filter rules (rules.debug) and found some interesting piece: the makro "pptp" is aligned to ALL ng interfaces starting by 0 (which is needed for pppoe dial in here in germany) and ending with ng15. But to my understanding ng0 isn't needed here! The rules for incoming pptp connections (tcp/1723 and gre) are "pass in"'s without an interface given, so they apply to ng0. And after a connection is established, an ng1 interface for that host is fired up, which the rules in "PPTP" Tab are applied to. As given in the m0n0 documentation, I testet with a rule, that let pass from any to any without restrictions and so made myself pretty "unsure" on the external if (ssh and http are now accessible without an additional security layer!).
I think if the dial-in is done via an ng interface (as pppoe does), the makro "pptp" should correctly state
pptp = "{ng1 ng2 ng3 …}"
and not begin with ng0, which leads us poor dial-in guys pretty insecure ;)
Please correct me if my thoughts have a mistake, but I'm testing that currently and don't see a reason the rules in the PPTP-rules-section should apply to ng0 aswell.Thanks
Grey -
I can confirm this. I wonder how that was undiscovered for such a long time! ??? I'll file a ticket. Thanks for reporting!
EDIT: http://cvstrac.pfsense.com/tktview?tn=973,6
-
At the moment quick workaround:
Login via Shell or Console and change dir to /tmp. Edit rules.debug and delete the "ng0" part in makro "pptp" (right on top of the file). Then reload the filter rules via "pfctl -f rules.debug". Worked for me this far and immediatly shut down the unwanted access from outside to web and ssh port.
Thanks for filing, hoba :)
