Suggestions
-
If you try to use another product do not pretend it to be your prefered product!
The labels tell you what it does and if you want it to do something else is none of our concern!Some limitations about WAN/LAN are already fixed in the planned 2.0 release.
-
@ermal:
If you try to use another product do not pretend it to be your prefered product!
The labels tell you what it does and if you want it to do something else is none of our concern!Some limitations about WAN/LAN are already fixed in the planned 2.0 release.
Your response is a little disconcerting to me and I find it extremely offensive. If the menus were labled correctly it would be much easier for new users to understand. It's only a suggestion and not an attack like your statement.
I was attempting to report some issues (i.e. NAT Outgoing rules only work on the WAN port, unless an incomming rule has a gateway setting to route traffic to a different port). Having a gateway setting on an inbound rule does not make any sense as it is mixing both inbound and outbound functionality in the same rule. It would make more sense to create 2 rules, a filtering inbound rule and a filtering outbound rule where the outbound rule also contains some routing information.
Alas, it is your application and you can take what I say with a grain of salt. Attacking users is not a very good way of doing business and I'm hoping that it was a misunderstanding on your part.
Good day…
-
I came from an IPCop and iptables-based background. I didn't find pfSense to be a "huge learning curve".
You said that if "the menus were labled [sic] correctly". You may have a different expectation of what should hang off each menu, but I don't think there are any menus (1.2.3) that are labelled incorrectly.
If you're not happy with it (you said "some one should really look at is adding"), feel free to improve it and submit your improvements so that we can all benefit from them.
As for "NAT Outgoing tab does not function as described", it does for me - perhaps you can elaborate on how it doesn't function as you expect it to?
"NAT and Rules menu items are miss named". No, they're not. You don't necessarily need or use NAT (ie. transparent bridge mode), and "rules" are exactly that. You don't necessarily want rules (ie. just routing), so the "NAT" is just that.
I think for 99% of installations, the default "LAN allow all outbound" and "WAN block all inbound" is the correct choice - the entire Home/SOHO router/firewall market also has this model. There will always be exceptions but there has to be a default and IMHO pfSense's default is pretty sensible. Naturally, if you have more sophisticated requirements then you'll be testing it in a lab environment first.
You add "the functionality doesn't match the documentation", which I largely disagree with. Some of the documentation needs updating but it's pretty accurate in describing the core functionality. It'd be great if you could contribute to the task of updating outdated documentation.
-
Hey Bern,
I come from a professional commercial products background, which is the disconnect. I did evaluate IPCop before selecting pfSense, but as you know IPCop has virtually no configuration control for networks with servers in the DMZ. Multi-NAT with pin holes is an absolute must and not supported by IPCop in any usable way. I would consider IPCop to be the "Home/SOHO router/firewall market" that you describe while pfSense covers the small to mid sized commercial market and even some large corporations.
I have contributed to several open source projects over the past 18 years, FreeBSD included, and it would not be prudent for me to make the discussed changes unless I was planning on creating a new product based on a branch from this one, which is something that I have no time for, nor interest in. As for the NAT Outgoing tab, are you running 2 or more WANs? If I create rules on each port to allow all incoming traffic and then create a NAT Outgoing rule to route specific traffic through a specific public IP on WAN2, I would expect that the outbound traffic would use that rule. However, the NAT Outgoing rule is ignored unless I create additional incoming rules with a gateway setting.
Typically, the NAT configuration settings are used by rules, filtering, and routing entries. They don't do any filtering or routing themselves, which is why I believe that they are mislabeled. Again, this is just my POV based on my background. Rules (a.k.a. filters, filter groups and filter sets) and routes apply to all traffic and normally have the ability to use a NAT configuration. The disconnect appears to be that the NAT configuration is used to control traffic rather than have the traffic controls use the NAT configuration. Does that make more sense?
Anywho, great response and I look forward to seeing what is in 2.0 once all of the functionality is there.
Take it easy,
Bill -
With pfSense, all rules are "incoming", but some of what you describe is a matter of perspective. There are really no "outbound" rules, per se, at all.
Instead of viewing traffic as going "out wan2 from lan2" in pfSense it is handled as "in lan2 out wan2" where lan2 is the TAB where the rule is found (and the interface the rule is matched on), the packet is inbound there, and the gateway on that rule is for wan2.
To me, this makes more sense because I have better control (not just by IP) of how and where traffic is allowed to flow. Indeed the rules could not be placed as "outgoing" because to be outgoing the rules would already have to be bound to a WAN-type interface, and at that point it would be too late to decide to route them out a different interface instead.
Also, if you have a pure-routed network, you would not want or need to involve NAT to influence routing in any way, so it would not be correct to call those purely "outgoing" rules either.
I do agree that some degree of "interface genericness" would be good, but that is already present in 2.0 so it's a moot point. :-)
-
Hey jimp,
I think that you indirectly brought up the true issue. Commercial products have filters and routes which are handled separately. In pfSense the direct route is hard coded to the filter (rule) where the UI states, "Leave as 'default' to use the system routing table. Or choose a gateway to utilize policy based routing.", which is rather confusing anyone not familiar with pfSense. It also does not give you the option to route through IP addresses that are not defined on the port.
Commercial products don't tie a gateway to a port and route based on routing rules exclusively. They either have separate rule sets for each, or filters that refer to a routing rule or group of routing rules. This allows multiple filters to refer to the same routing rule, which allows you to change just one routing rule instead of every filter rule that refers to it. If using NAT, the routing rules also have the option of defining a public address that applies to both incoming and outgoing packets, something that must be done manually in pfSense.
As I stated earlier, NAT should sit on top of routing as a tool that a route has the option of using. I'd like to know more about v2.0 though. Are all of its features functioning?
Thanks,
Bill -
We'll probably have to agree to disagree on this stuff, to be honest. I rather like the way that pfSense handles things separately, and the places made sense to me without ever having touched pfSense before.
One of the biggest selling points for me about pfSense is that it does not behave like a "commercial product." :)
In 2.0, which is shaping up nicely but is very much a work in progress, there are ways to define multiple gateways, and I believe someone is working on rule grouping. Coupled with aliases, much of what you are talking about is possible, though perhaps not organized the way you'd prefer.
It's worth trying, but be warned that some things are bound to be broken at any given point in development.
-
Hey jimp,
That's cool. If everyone agreed on everything, it would be a rather boring world. I look forward to taking a look at 2.0 when I have some extra time. BTW, I've been assuming that incoming rules only apply to requests to open a new connection (i.e. the TCP established connection bit is 0). Is this correct?
In either case, how do you write rules that only apply to new connections, or rules that only apply to existing connections?
Thanks,
Bill -
Typically the rules only apply to "new" connections, and not current connections. The way that pf works, existing states will trump firewall rules every time. So in order to make a rule apply to an existing connection, its state must first be cleared.
In the WebGUI, you can clear a state for an individual connection by finding it in the list (Diagnostics > States) and clicking the 'x' next to its line, or by resetting the state table entirely. You can also do this with pfctl at the command line.
I don't think there is a way (yet?) to specify which tcp flags a rule applies to, or you might be able to accomplish some of what you're after that way. Most of the time it is not necessary to only apply rules to an existing connection, as the state table will take care of allowing the proper traffic to flow back from a connection initiated the right way.
-
Thanks a bunch. I had some filters in the routers that were using this bit, but the state tables may be the way that pfSense deals with it, meaning that I don't need to. I'll need to take a closer look at the old filters. I moved away from doing this in the routers due to size limitations and the difficult procedures required to backup then up every time any change to the configuration is made.
