How to allow opt only to wan
-
It is easier to read and understand if you use block/reject rules instead of inverted allow rules.
Allow This Firewall ICMP echo request
Allow This Firewall tcp/udp/53 (DNS)
Block This Firewall
Block LAN net
Allow * * * * *https://doc.pfsense.org/index.php/Firewall_Rule_Basics
https://docs.netgate.com/pfsense/en/latest/firewall/restrict-access-to-management-interface.html
-
@KOM I found that using an alias to block all RFC 1918 addresses is simpler than a bunch of block rules particularly if you plan on having many OPT interfaces (VLANs), but you said it much better!
Allow This Firewall ICMP echo request
Allow This Firewall tcp/53 (DNS)
Block RFC1918
Allow * * * * * -
That works, too. I was just noting that inverted rules should be avoided unless you have a weird edge case.
-
@awebster said in How to allow opt only to wan:
Allow This Firewall tcp/53 (DNS)
TCP & UDP please :) Also let's go for udp/123 for using NTP to define a small, nice and simple set of basic infrastructure services ;)
-
While ! rules can work, you need to make sure you have no vips that could cause issues with them. And yes as KOM stated already is prob better to use an explicit deny, it is much easier to read. And less likely to be a problem.
Here is a example set of rules that you could use on such an isolated vlan. It allows for min services, ping, dns and ntp while blocking all other access. The this firewall built in alias prevents it from access say even the pfsense wan IP directly (which would normally not be rfc1918 space) Uses reject vs block, to tell any local devices - hey that not going to work faster then waiting for them to just time out and keep sending retrans.
The rfc alias contains all the rfc1918 networks (10/8,172.16/12,192.168/16) this way if you bring up other networks in the future it will not be able to get to them either.
You might also want to log your rejects, so that you can see if something is attempting such access.
-
Aah someone besides me that also uses "reject" on the inside rather than just "block"ing it away
Have to remember the "This Firewall" reject though, I tend to forget these (and expose the firewall's WAN IP if not a private one that way). Thanks for the reminder :) -
Yeah reject is better on the local side, never something you would put on your public facing interfaces ;)
-
@johnpoz said in How to allow opt only to wan:
While ! rules can work, you need to make sure you have no vips that could cause issues with them. And yes as KOM stated already is prob better to use an explicit deny, it is much easier to read. And less likely to be a problem.
Here is a example set of rules that you could use on such an isolated vlan. It allows for min services, ping, dns and ntp while blocking all other access. The this firewall built in alias prevents it from access say even the pfsense wan IP directly (which would normally not be rfc1918 space) Uses reject vs block, to tell any local devices - hey that not going to work faster then waiting for them to just time out and keep sending retrans.
The rfc alias contains all the rfc1918 networks (10/8,172.16/12,192.168/16) this way if you bring up other networks in the future it will not be able to get to them either.
You might also want to log your rejects, so that you can see if something is attempting such access.
This was a nice way to do it thanks for the help, but a question are the 2 block/reject rules needed ?
Or will it only be needed the rfc-1918 block/reject rule as all the ips so is under that alias will be under the rfc-1918 address pool
From what i did read i belive "this firewall" is all the ips to all the interfaces on the firewall , so is most likely something like 192.168.1.1, 192.168.2.1, 10.0.0.1 and that will be blocked by the rfc alias or???? -
Normally firewall has a WAN ip that is public.. So if you do not use the built in firewall rule, or put in a wan address block.. Your block rfc1918 would not trigger..
So as always when wondering what you rules are going to do, walk down from top to bottom with your traffic and see what rule triggers or not.. If it gets to the end with no rules that allow or block triggering - then it would be blocked by the default deny that is not shown..
So lets say I took out that reject to firewall, and lets assume my firewall wan IP was 1.2.3.4, so now lets say someone want to hit the gui on my wan IP..
- not triggered - its icmp and my dest is tcp 80 trying to hit gui
- nope not dns
- nope not ntp
- not there
- Nope dest is not rfc1918
- yes my sorce is test net, and any is my dest port, and any is my dest IP.. Yup allowed, so now devices on this network could access pfsense webgui without that reject "this firewall rule"
If you wan IP is rfc1918, ie its behind a nat - then yeah you wouldn't need that rule. But you could use it as a safety net, on the chance you change your network and pfsense now has a public IP.
-
This post is deleted!
