Security Zones
-
@rickandaj said in Security Zones:
Would using interface groups be useful here?
depends on how many interfaces you have.. If you have like 4 I would say no ;) I have 8 different networks/vlans - rules are all slightly different.. I see no advantage of "grouping" them..
while it might take a few extra seconds to put rule on each interface - later it makes it much easier to see the rules vs being worried, oh I have rules in groups, oh I have rules on interface, oh I also have rules in floating, etc..
Unless you have lots of interfaces and would be a lot of work to say block all of these different networks/vlans from talking to lan that I know I don't want any of them to do, I see no point in doing that in floating or a group.
You will thank yourself later when you don't have to look to multiple areas where you might have a rule that allows or blocks something. And its easier to make sure your order is correct if the rules are just on the interfaces.
I only use the floating tab for outbound rules.. Because that is only place you can put outbound rules.. All other rules I would put on each interface, and no I wouldn't group them.. Now if I had a 100 interfaces I might rethink that ;)
-
Got it! Thanks.
-
@rickandaj said in Security Zones:
I want vlan-A to have access to Vlan-B. However, vlan-B cannot access vlan A, C or D.
very quick example on VLAN-A interface:
allow from VLAN-A Net to This Firewall (for DNS, port 53 tcp/udp)
[optional] reject from VLAN-A Net to This Firewall (port 443/22/80)
allow from VLAN-A Net to VLAN-B Net
reject from VLAN-A Net to Any [did you want to prevent A outbound also?]VLAN-B interface:
[optional] allow from VLAN-B Net to This Firewall (for DNS, port 53 tcp/udp)
reject from VLAN-B Net to VLAN-A Net
reject from VLAN-B Net to VLAN-C Net
reject from VLAN-B Net to VLAN-D Net
reject from VLAN-B Net to anyExplicitly rejecting the other VLANs is unnecessary if "any" is rejected but it's clearer.
pfSense has hidden rules to allow DHCP if DHCP is enabled on an interface.
-
SteveITS, Thank you! However, a little clarification please. You use reject vs block, any specific reason? Additionally, VLAN-B is given access specifically for DNS, so should there be another rule explicitly rejecting/blocking admin access - to web or SSH for administration on the box from VLAN-B?
-
The reject action sends back a TCP close to the client immediately so it knows that's not allowed. If it's set to block the clients just keeps trying until it times out. So for an internal interface it makes clients quicker to respond.
The allow rule on VLANB for DNS is only for port 53 so not other access is passed by that.
-
@rickandaj here is a example of a locked down vlan.. It can not talk to any of my other networks. The reject to rfc1918 alias (all of my other networks are rfc1918). The use of such a blanket alias allows you to add another network as some future point and not having to worry about blocking this network from talking to it.. Since any new network you bring up is more than likely going to be a rfc1918 network.
But it does allow ping to pfsense IP on this network, and dns, ntp. But blocks all other access to any other pfsense IP (be the public wan IP for example) so this would prevent access to webgui or ssh, etc.
Yes using reject locally is common practice, because it should prevent retrans and timeouts and just tell the local client right away - hey your not getting there so it shouldn't keep trying with a retransmission, etc.
I wouldn't suggest using reject on the wan.. You don't want to create outbound traffic everytime someone tries to talk to a port you have them denied from, etc.
-
@stephenw10 Thanks for the clarification!!
-
@johnpoz Thank you for the visual! This will certainly help with my set up. I have 20 vlans that I'm setting up on the pfSense box replacing a Juniper. This will certainly help with my transition. Again thanks.
-
@rickandaj said in Security Zones:
I have 20 vlans
So to help in setting those up.. You can setup one that has your basic rules you want... Then just copy them to your new interface, and it will convert the source and destination address to the new interface..
Here I fired up a new vlan, and copied my test rules to the newvlan.
You would then just need to tweak or add/delete what you want on the new rules.
-
@johnpoz Thank you so much! I will get to test this out shortly.
-
@johnpoz Just a quick question on the interfaces along with the security zones? If I need a separate thread let me know? I've noticed that when I create the vlans and assign them to a parent interface, I don't get the DHCP server option for the vlans, I can create the rules with no issue - I am using the Kea DHCP? Is there some checkbox I missed that I need to be using? Incidentally, all of this is being done on the CE version - 2.7.1. I don't get my 6100 appliance until tomorrow. Doing all of the pre-configuration work now when I can make all of the foopahs that I can, without impacting.... BTW Happy Thanksgiving!!
-
@rickandaj did you assign them to interfaces?
https://docs.netgate.com/pfsense/en/latest/vlan/configuration.html#web-interface-vlan-configuration -
@rickandaj also don't forget you have to actually enable the interface and setup its IP and mask once you assign the vlan. Common mistake users often make is the mask defaults to a /32 so no dhcp would be available. Until you setup a mask that allows for Ips to be assigned via dhcp.
-
@SteveITS Yes I certainly did. See below:
Maybe my error will jump off of the page for you? Thanks.
-
@rickandaj well you didn't include what you set the IP and mask to for that interface - I would bet you just left it on the /32 which is why no dhcp wouldn't pop up as an option
-
@johnpoz oops... You were correct! In previous setups I did some static routes to mimic my outgoing Juniper.... With that fixed, I can move on to the next phase. Crash and burn, I mean, testing LOL. You've been a great help as I journey to the pfSense world. Cheers.
