Invert match doesn't work
-
you really need to post a screen shot of your rules if you want people to chim in on why they may or may not do what you want.
-
@johnpoz offcourse….btw is it maybe the 1st rule (default rule) on the LAN for port 22/80/443 that is the "culprit"?
-
I don't see any inverted rules in your screenshot.
-
btw is it maybe the 1st rule (default rule) on the LAN for port 22/80/443 that is the "culprit"?
That first rule, the Anti-Lockout Rule, is there to make sure you don't do something dumb and literally lock yourself out of the GUI or SSH. That's all.
-
Nope don't see any ! or inverted rules..
-
you are both right ofcourse, I only thought that if this default rule is there it will always allow access to the LAN, whatever rule you than create in any other subnet.
So here is the rule set for the WLAN subnet
-
so your wlan net would allow anything that is NOT lan net.
I use the same sort rules and have no issues with them.. Derelict would suggest you just change that to a specific block/reject that you put above your allow any.. And this is cleaner way to look at rules.. But the ! lan net should work… I use them on all my vlans that I block access to any of my other vlans with a ! rfc1918 alias I created.. So this allows access to internet but blocks all access to any of my other vlans which are all in rfc1918 space.
Keep in mind states could still be active that would allow traffic, and if your using vips there were some issues with ! rules I do believe..
If your concerned with the ! rule, just put a block/reject rule above it that specifically blocks access to lan net.
Rules are evaluated top down, first rule to trigger wins, no other rules are evaluated as traffic enters an interface.
Do you have anything in floating that might allow the traffic before the wlan rules are even evaluated?
-
Thanks for all your time, well this rule should block access to the LAN, Yet here, it doesn't. I have removed the inverted rule to the LAN and access to the LAN subnet was gone. Then I added a block tot the LAN added 6 allow WLAN to anywhere for port 80-443-21-25-110-143
I have no idea why this inverted rule doesn't do it's work any more. As I hate things I do not understand, can I check if the GUI makes the acquired chances to the pf firewall rules using the CLI? -
states might of been active when you put in a rule that blocks you have to kill any active states.
-
I understand that, but after I disabled the inverted rule, I could not access the webgui of a managed switch (as example) the moment I enabled it, I could :o
-
managed switch where? That rules says you can go anywhere you want as long as not lan net which is what nat network? you have a bunch of other networks there..
So if say network of lan was 192.168.1.0/24 that rule says you can go anywhere you want as long as dest is not 192.168.1.0/24… It could be some downstream network that you get to via lan net even, etc. Maybe you are running vip with different layer 3 on lan net... Have seen lots of people think its ok to run multiple layer 3 on the same layer 2..
If you were running say 192.168.2/24 on your lan network that would of be allowed since lan net just expands to the network you have on your lan interface nothing more.
-
rfc1918 alias I created.. So this allows access to internet but blocks all access to any of my other vlans which are all in rfc1918 space.
Could you give an example of this? I have 7 VLAN's and it's a lot of work to block everyone manually?
Cheers Qinn
-
Create an alias.
Add the subnets
192.168/16
172.16/12
10/8
Call the alias RFC1918 -
^yup that is what I have exactly
-
Thanks to you both!!
Could you show me an example how to in the rules?
Cheers Qinn
-
^yup that is what I have exactly
I now have this, I have only allowed port 53 on the gateway, this seems enough. Maybe a stupid question, but why don't it need an open port on dhcp, orto rephrase that why does it get an IP address?
-
When you enable dhcp server, pfsense creates rules that are not shown in the gui. There are a few rules like this.
Here is the thing if they didn't auto create the dhcp rules - every other day there would be a question about dhcp not working.. Did you create the firewall rules, lets see them because 999.99999 out of 100 you did it wrong ;)
If you are wanting to block guests to all things yours. Is your wan public or rfc1918? Since your guest could hit your gui via the wan IP coming from the "lan" side like they are.. This is the good use of "this firewall" built in alias. This is any IP the firewall has.
I personally would allow ping to the pfsense address, so you can validate your guest can talk to pfsense.. And you sure you want guest to only have tcp outbound? So you don't want them to be able to ping anything out on the internet or use udp?
-
When you enable dhcp server, pfsense creates rules that are not shown in the gui. There are a few rules like this.
Here is the thing if they didn't auto create the dhcp rules - every other day there would be a question about dhcp not working.. Did you create the firewall rules, lets see them because 999.99999 out of 100 you did it wrong ;)
If you are wanting to block guests to all things yours. Is your wan public or rfc1918? Since your guest could hit your gui via the wan IP coming from the "lan" side like they are.. This is the good use of "this firewall" built in alias. This is any IP the firewall has.
I personally would allow ping to the pfsense address, so you can validate your guest can talk to pfsense.. And you sure you want guest to only have tcp outbound? So you don't want them to be able to ping anything out on the internet or use udp?
Aha, I did not know that about port 67 (DHCP), it seems logic.
I don't understand what you mean here "Is your wan public or rfc1918?" could you explain a bit more? Although, I don't understand it Yet, I think I have added that rule, I choose a reject or would you advise a block?
-
"Is your wan public or rfc1918?" could you explain a bit more?"
Huh? How is it you just created a alias for rfc1918 space but you do not know what it is?
If your wan starts with 10.x or 172.16-31.x or 192.168.x then its rfc1918 and your alias rule would block all access. If it was public say 62.14.45.x then your rule would not block it and your allow on the bottom would users hit your wan IP, ie the gui or ssh etc. from this network.
Rules are evaluated at they enter a interface, top down first rule to trigger wins, no other rules are evaluated. So while default on wan is deny - that is when your coming from the WAN direction towards pfsense. If your behind pfsense you can hit that IP all day long on any service listening on it. This is where the "this firewall" rule alias comes in handy. For example maybe you want opt1 net to go to your lan net to get to stuff. But you don't want opt1 net to be able to get to the web gui on the lan IP..
-
That rule will not block access to the internet even if the WAN is RFC1918-addressed. It would block access to the things on WAN net like the ISP gateway in that case.
