How to allow opt only to wan

awebster

No, that won't work.

You need to use ipv4 opt2 * * "! LAN Net" * *
! = Invert match
You want to allow it to go anywhere EXCEPT LAN Net.

vidarne77

Thanks

so if i put in an alias all the interfaces i dont want it to goto and then use invert match that to will work to?

awebster

@vidarne77 You could do that, I've found what works best for me is to create an alias for all RFC 1918 addresses (non-routables) and use that as a DENY rule early on in the ruleset on the OPT interfaces. Assuming it is placed correctly, you never need to revisit that rule.
This prevents any clients on any OPT interfaces from talking to anything "inside" the network.
You can add any allow rules before that if you need to allow specific things like getting to a print server on the LAN subnet.

KOM

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

awebster

@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 * * * * *

KOM

That works, too. I was just noting that inverted rules should be avoided unless you have a weird edge case.

JeGr

@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 ;)

johnpoz

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.

JeGr

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 :)

johnpoz

Yeah reject is better on the local side, never something you would put on your public facing interfaces ;)

vidarne77

@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????

johnpoz

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.

jhonpacker

This post is deleted!