Why binds pfSense (1.2.3) dameons to every interface
CollateralD last edited by
is there a certain cause why pfSense binds most dameons (lighttpd, sshd, dnsmasq)
to all interfaces?
I know that the default policy for pf do not allow to access these dameons except
But IMHO it is pretty useless to bind with one piece of "software" (sshd, dnsmasq,…)
to interfaces (even where the function is not needed), and restrict access with
another (even pretty good) piece of "software" (pf).
(Wasn't this "bind everything to everything" a major issue in the last decade on all
Another thing I would like to comment is the concept of "WAN" and "LAN". I think it
comes from the mainly purpose of a fw, the bad side and the good side. Regarding
my first point, in a concept of "WAN" and "LAN" I would put bindings (in standard)
only to the "LAN" interface.
Nowerdays there are so extrem different ways how pfSense is used so maybe this
WAN-LAN (and therefore "hardcoding" different things to WAN or LAN) is somehow
"outdated" and a better approache would be to let the admin take care of that,
Interface - IP - assign custom name - assign purpose (good side|bad side|nirvana|and-so-on).
The auto-generated rules respectively the behaviour is then not made on the
decision if it is WAN or LAN or OPT or whatever. It is made on the config purpose.
Just my 50cents.
Apologise if I was somehow to negativ or offended someone.
Guest last edited by
Most of what you're talking about are holdover conventions from m0n0wall which have been maintained for ease of use. There's a case to be made for not binding important services like the webGUI and OpenSSH to all interfaces by default, however, there are plenty of difficult to manage edge cases that require it. At the end of the day, these were design decisions made to assist the greatest number of users. Certainly there is room for improvement, and pfSense is improving regularly, but feedback like yours helps raise important questions and spawn useful debate. Hopefully some of the devs will sound off with their views.
cmb last edited by
Because many people open the web interface or SSH from specific remote locations for management and want to do so without having to NAT. Changing that now would break thousands of upgraded systems. I agree it wouldn't be a bad idea to have an option to only bind to specific IPs. Patches welcome.