Blocking ALL WAN Outbound, then selectively Allowing Outbound
-
I found the only way to do this is with Floating rules. But's it's a bit messy and tedious.
And, since my WAN Interface is NAT-ed to my OPT1 Inteface, I had to use TAGs.Now, for EVERY Outbound connection I have to create a special FLOAT rule just for that connection, along with a WAN rule also for that connection.
There seems to be no "Easy" way to simply click and add Easy Rules for this as is the case with regular WAN, LAN and OPT rules.So in pfSense, you have to create TWO rules for each outbound connection...one under WAN and another under FLOAT.
Messy and tedious.Any know a cleaner, easier way to do this?
On my Watchguard firebox, everything is blocked both directions by default, so you can easily set up Global rules for Inbound AND Outbound traffic which is desirable (to me). And since the default on the Firebox is no outbound allowed on the LAN,I just create LAN rules to allow the connections I want to go out.
It's like pfsense (being only software) lacks some abilities that hardware based firewalls have since WatchGuard Fireboxes and other other similar hardware firewalls can incorporate special IC chips to do things pfSense cannot?
-
I suspect that you have a basic misunderstanding of how pfSense works and evaluates traffic. Firewall rules are applied as traffic enters an interface, not as it leaves. So if you want to block all traffic from your LAN, then you put your rules on the LAN interface. You typically only put rules on WAN to allow your NATs, since the default block rule (an invisible deny-all rule at the bottom of the ruleset) will block all unsolicited traffic by default. The floating rules page is most usually used for matching traffic-shaping rules.
That said, I haven't seen too many good reasons to block everything and then start whitelisting. While it may sound great from a security perspective, it very quickly becomes a nightmare to manage and you end up with upset users who can't do what they want until they bug you to figure out what's being blocked.
What is the real goal that you are trying to accomplish here?
-
Humm, was asking myself the same question.
Thanks, @KOM, you saved me some time.So, some other questions :
Why nailing down your traffic that way ? You do not trust your OS ? Your software ? Other people on your LAN(s) ? What might be seen upstream ?
@HansSolo : I hope someone pays you well for what your doing, because if not, stop playing a cop on your network. Isolate your own traffic. Make it work for you, and you'll be fine.
Even on my public captive portal, accessible for the clients in my company, a hotel, I use just some 10 firewall rules on the portal interface (I've nothing on Floating, neither on WAN). Just to stop netbios, pure smtp and that kind of stuff. When things go nasty, I kick in a traffic shaper, and that's it. Works fine for me, for many years now.It always boils down to : port 80 and 443 are open, probably also someSMPT(S), IMAP(S) and POP(S) ports.
99,99999 % of all troubles from the Internet come in on these ports. Over SSL of course, so not and never visible for you. -
@KOM said in Blocking ALL WAN Outbound, then selectively Allowing Outbound:
I suspect that you have a basic misunderstanding of how pfSense works and evaluates traffic. Firewall rules are applied as traffic enters an interface, not as it leaves. So if you want to block all traffic from your LAN, then you put your rules on the LAN interface. You typically only put rules on WAN to allow your NATs, since the default block rule (an invisible deny-all rule at the bottom of the ruleset) will block all unsolicited traffic by default. The floating rules page is most usually used for matching traffic-shaping rules.
That said, I haven't seen too many good reasons to block everything and then start whitelisting. While it may sound great from a security perspective, it very quickly becomes a nightmare to manage and you end up with upset users who can't do what they want until they bug you to figure out what's being blocked.
What is the real goal that you are trying to accomplish here?
I suspect you may not have much experience with enterprise level firewalls. Or maybe you are only familiar with hobby firewalling?
Consider what you just said. If that were the case, firewalls would not have (or need) the capability for Outbound rules.
Please don't mislead people into a false sense of security with Inbound rules only.In enterprise environments, it is common to have rules blocking Outbound traffic such as employees trying to visit Internet sites. On my Watchguard Enterprise firewalls, this is a very simple task. However, with pfsense it is far more difficult. Or at least it seems at this point as I'm fairly new to pfsense.
I am providing a link that you might read at your leisure to gain a bit of insight in the the multitudes of reasons you might want to learn about Outbound rules and their benefits.
-
Truthfully HansSolo you made a couple of the guys here in my room laugh talking about enterprise firewalls and Watchguard in the same breath..
They like to charge the premium rate but.. Ill stop there.
There are allot of reasons to control outbound traffic.. Im with you there. I would think especially operating a network where you cannot control the client devices.. But usually someone will come along and figure yet another way to get past your port blocking.
As you work with pfsense and become more familiar with its configuration options I think you will find it to be a much nicer solution than many of the other options out there. Take advantage of all the videos the pfsense guys have produced over the last few years. There is allot to keep you occupied for a while.. https://www.youtube.com/channel/UC3Cq2kjCWM8odzoIzftS04A
https://docs.netgate.com/pfsense/en/latest/general/comparison-to-commercial-alternatives.html
-
@chpalmer said in Blocking ALL WAN Outbound, then selectively Allowing Outbound:
Truthfully HansSolo you made a couple of the guys here in my room laugh talking about enterprise firewalls and Watchguard in the same breath..
They like to charge the premium rate but.. Ill stop there.
There are allot of reasons to control outbound traffic.. Im with you there. I would think especially operating a network where you cannot control the client devices.. But usually someone will come along and figure yet another way to get past your port blocking.
As you work with pfsense and become more familiar with its configuration options I think you will find it to be a much nicer solution than many of the other options out there. Take advantage of all the videos the pfsense guys have produced over the last few years. There is allot to keep you occupied for a while.. https://www.youtube.com/channel/UC3Cq2kjCWM8odzoIzftS04A
https://docs.netgate.com/pfsense/en/latest/general/comparison-to-commercial-alternatives.html
My pleasure. Education and entertainment can be partners.
I've got pfsense fairly well configured now, but still lots to learn.
Basically, I stumbled onto pfSense only because my tried and true Watchguard device at my Home Office failed due to age. (I tend to keep them going way too long).To be sure, I'm impressed with pfSense and I like it. Most of it. Not too happy with the Outbound Filtering at the moment. I can get it to work, but man...it's messy and tedious. Could be because I'm still a pfsense noob.
As mentioned in another post, it's my "opinion" that pfSense, being a software only solution, is at a disadvantage because it cannot be supported by proprietary IC chips that can, for example, contain stored tables or extremely complex routines that can make supporting some functions such as policy filtering, at least faster, if not much simpler. The pfsense team, in that respect (imo) has done a remarkable job.
Now then, about WatchGuard,....other than milking you for $$$ (Which they ALL do).....(and I assure you, I have no connection with them AT ALL), can you site some specific technical shortcomings with WatchGuards upper tier products that are "laughable". I would find it educational to know what you know that I may not about them.
I ask because at some point, some of my clients may have (or inquire about) WG Enterprise boxes. And what do you use and recommend?
All the best.
-
@HansSolo said in Blocking ALL WAN Outbound, then selectively Allowing Outbound:
Not too happy with the Outbound Filtering at the moment.
You still seem to not get it.. While yes pfsense can filter in the outbound direction on an interface, and in some setups this might be necessary... But to stop users from going outbound on port X, you don't need nor should you be place the rules on the floating tab.. Unless you need these rules to apply to multiple lan side interfaces..
Lets keep it simple for example... You wan wan (internet) interface, and your local network lan..
If you don't want users on lan to get to Port X or port Y then you block that on the lan interface... its that simple.. No user can now go to X or Y, period.. And pfsense did not have to process the traffic through its lan interface to just find out - hey not going to let it go out the wan interface anyway.
Rules are evaluated, top down, first rule to trigger wins, no other rules are evaluated. By default there is deny... So if you remove the default any any rules from lan interface, no traffic is allowed outbound from lan... Create rules to allow the traffic you want and your done..
Really could be done with like one rule.. An an alias that contains the ports you want to allow.
-
@HansSolo said in Blocking ALL WAN Outbound, then selectively Allowing Outbound:
it cannot be supported by proprietary IC chips that can, for example, contain stored tables or extremely complex routines that can make supporting some functions such as policy filtering,
And I hope you do not think that Watchguard does..
Did you read my link above?
Just one paragraph from it-
âHardwareâ firewalls are better mythCommercial firewall companiesâ marketing departments have done a fine job ingraining the myth of âhardware firewallsâ into some peopleâs minds. The reality is there is no such thing as a âhardware firewall.â All firewalls are hardware that runs software. Most commercial firewalls are based on BSD (same as pfSense) or Linux. Numerous commercial firewalls run many of the same underlying software programs that pfSense uses. Many commercial alternatives run on x86 hardware thatâs no different from what people use for pfSense. In fact many people have loaded pfSense on hardware that used to run their commercial firewall, including Watchguard, Nortel, Barracuda and more.
We're running both an XTM5 and XCS box here. The XTM box was only a year old when I got a hold of it. We use every Ethernet port on it for different sub-nets in use here at my primary location. Plus it runs multiple point to point VPN's without a slowdown. Great equipment.
We work around schools allot. The IT departments in schools are constantly trying to keep ahead of the kids and the new methods they use almost daily to bypass the "rules" and security measures put in place. While the IT staff still use some outbound port blocking they rely on allot of what they consider "better security methods".
What version of the Watchguard OS are you most familiar with and using?
-
I managed Check Point firewalls for years starting with Nokia IPSO-based appliances and then later Check Point branded appliances. No custom chips in any of them. All were pure software. The IPSO operating system owed its origins to FreeBSD and Check Point's SPLAT (Secure Platform OS) and later GAIA OS were both hardened versions of CentOS/RedHat Linux with a Check Point authored software package on top. No custom hardware anyplace. In fact, l frequently used both in VMware virtual machines in my lab although the IPSO VMs were a bear to configure because Nokia did use a custom NVRAM chip to hold some configuration info and you had to fake that out in the VM. I did it by using FreeBSD 7.1 to create a very basic setup and then copying the IPSO image on top of it using
dd
.The biggest difference I see between pfSense and the Check Point products is the Check Point stuff can suck a whole lot more money out of the corporate treasury each year for maintenance and support contracts and licensing fees ... .
Later Edit: After thinking about it some more, it would be unfair to suggest pfSense and Check Point are identical in every way. Each offers its unique advantages. For a large corporate enterprise network, Check Point does have some nice management features that pfSense currently lacks -- mainly Check Point's SmartCenter server and all the firewall deployment, management and log consolidation functionality it offers. You can do some similar things with pfSense and third-party tools, but it's not as clean at the moment. Of course that Check Point functionality will cost you a rather substantial sum (very quickly rising into the 6-figures range in US dollars). pfSense costs you exactly zero US dollars if you support yourself, and still is very competitively priced if you purchase Netgate support.
However, out of the things I mentioned above, nowhere did I say that expensive product was any more secure than the free one. In terms of security, when managed by a competent admin, the free product and the expensive one are identical. The expensive one just offers some management conveniences.