How to prevent OPT nets from accessing LAN nets
-
That rule should block, did you reset your states after there rule change to ! Lan net. Any existing states would allow the traffic.. So you can either reset them all or look through them and kill the ones allowing your traffic you want to block.
-
That rule should block, did you reset your states after there rule change to ! Lan net. Any existing states would allow the traffic.. So you can either reset them all or look through them and kill the ones allowing your traffic you want to block.
Reset the states from Diagnostic->States, doesn't work. My android box (192.168.2.x, OPT) still can browse all my NAS's (192.168.1.y, LAN) folders.
Do I have to add a firewall rule on LAN interface to block all traffic from the OPT nets as source?
-
I still can see the traffic went through from States table:
-
No you do not have to add a rule on lan..
So when you cleared your states, you then looked and there was no state?
I have rules that block traffic just like that !, that rule says you can go where ever you want as long as not 192.168.1.0/? Whatever your lan network is… So you might have a problem with your alias, did you renumber lan net?
Try putting in the rule with specific network 192.168.1.0/? your mask is and reset your states.
-
No you do not have to add a rule on lan..
So when you cleared your states, you then looked and there was no state?
I have rules that block traffic just like that !, that rule says you can go where ever you want as long as not 192.168.1.0/? Whatever your lan network is… So you might have a problem with your alias, did you renumber lan net?
Try putting in the rule with specific network 192.168.1.0/? your mask is and reset your states.
Thanks. changed to 192.168.1.0/24, and reset states, worked. Now, How do I know what "LAN net" is wrong, since its pre-defined, which I never touch it??
-
LAN net should be literally your LAN network as it is defined. Your LAN is 192.168.1.0 and OPT1 is 192.168.2.0… did you happen to use a /16 mask or something weird like that?
-
If you renumber it, and didn't reboot maybe its holding the original 192.168.0/24 I believe.. But I have never ever seen that..
Off the top I do not know how to view that the current values of those macro's are.. Have to look into how you would do that.. If there is a way??
I would prob just reboot and then try your rule with lan net.. you can for sure see that the rule actually is with
pfctl -sr
either from the command under diag, or if you ssh to pfsense, etc. Or actually at the console.
The rules there list that actual networks and not the name.. so for example
I have a rule that says allow in on ipv4 and v6 (see attached) allow
But when I look at the actual rules I see this
pass in quick on em2 inet proto udp from 192.168.2.0/24 to <ntpsrv>port = ntp keep state label "USER_RULE: Allow NTP"
pass in quick on em2 inet6 proto udp from 2001:<snipped>:2::/64 to <ntpsrv>port = ntp keep state label "USER_RULE: Allow NTP"Which are my actual networks on my WLAN net both ipv4 and ipv6
edit:
KOM's idea of wrong mask could also be why it was allowed. But as above you can always validate what your gui rules are exactly with the above command. Your aliases will popup what they are in the gui if you put a mouse over them… But variables like Lan net or Lan Address do not do that.
</ntpsrv></snipped></ntpsrv>
-
@KOM:
LAN net should be literally your LAN network as it is defined. Your LAN is 192.168.1.0 and OPT1 is 192.168.2.0… did you happen to use a /16 mask or something weird like that?
No. I didn't. but where should I look into it?
-
In your interface settings..
easy way would be status, interfaces would show you the mask on your interfaces. Or Interfaces, then click into say lan and or your opt interface and where you set the IP you would see the mask..
-
If you renumber it, and didn't reboot maybe its holding the original 192.168.0/24 I believe.. But I have never ever seen that..
Off the top I do not know how to view that the current values of those macro's are.. Have to look into how you would do that.. If there is a way??
I would prob just reboot and then try your rule with lan net.. you can for sure see that the rule actually is with
pfctl -sr
either from the command under diag, or if you ssh to pfsense, etc. Or actually at the console.
The rules there list that actual networks and not the name.. so for example
I have a rule that says allow in on ipv4 and v6 (see attached) allow
But when I look at the actual rules I see this
pass in quick on em2 inet proto udp from 192.168.2.0/24 to <ntpsrv>port = ntp keep state label "USER_RULE: Allow NTP"
pass in quick on em2 inet6 proto udp from 2001:<snipped>:2::/64 to <ntpsrv>port = ntp keep state label "USER_RULE: Allow NTP"Which are my actual networks on my WLAN net both ipv4 and ipv6
edit:
KOM's idea of wrong mask could also be why it was allowed. But as above you can always validate what your gui rules are exactly with the above command. Your aliases will popup what they are in the gui if you put a mouse over them… But variables like Lan net or Lan Address do not do that.</ntpsrv></snipped></ntpsrv>Serious issue now. As long as I changed back to ! Lan net, I can access my NAS again. and I don't see anything wrong when I ran "pfctl -sr"
-
In your interface settings..
easy way would be status, interfaces would show you the mask on your interfaces. Or Interfaces, then click into say lan and or your opt interface and where you set the IP you would see the mask..
Here you go:
-
So when you ran the -sr what did you see for the rule when you put in ! lan net?
-
So when you ran the -sr what did you see for the rule when you put in ! lan net?
Using ! Lan net: (10.10.10.1 was auto added by pfBlockerNG as the DNSBL Virtual IP)
block return in quick on igb2 inet proto tcp from 192.168.2.0/24 to (self) port = http label "USER_RULE: Disallow OPT to access webGUI, SSH" block return in quick on igb2 inet proto tcp from 192.168.2.0/24 to (self) port = https label "USER_RULE: Disallow OPT to access webGUI, SSH" block return in quick on igb2 inet proto tcp from 192.168.2.0/24 to (self) port = ssh label "USER_RULE: Disallow OPT to access webGUI, SSH" block return in quick on igb2 inet proto udp from 192.168.2.0/24 to (self) port = http label "USER_RULE: Disallow OPT to access webGUI, SSH" block return in quick on igb2 inet proto udp from 192.168.2.0/24 to (self) port = https label "USER_RULE: Disallow OPT to access webGUI, SSH" block return in quick on igb2 inet proto udp from 192.168.2.0/24 to (self) port = ssh label "USER_RULE: Disallow OPT to access webGUI, SSH" pass in quick on igb2 inet from any to ! 192.168.1.0/24 flags S/SA keep state label "USER_RULE: 10/100Mbps LAN" pass in quick on igb2 inet from any to ! 10.10.10.1 flags S/SA keep state label "USER_RULE: 10/100Mbps LAN"Using !192.168.1.0/24:
block return in quick on igb2 inet proto tcp from 192.168.2.0/24 to (self) port = http label "USER_RULE: Disallow OPT to access webGUI, SSH" block return in quick on igb2 inet proto tcp from 192.168.2.0/24 to (self) port = https label "USER_RULE: Disallow OPT to access webGUI, SSH" block return in quick on igb2 inet proto tcp from 192.168.2.0/24 to (self) port = ssh label "USER_RULE: Disallow OPT to access webGUI, SSH" block return in quick on igb2 inet proto udp from 192.168.2.0/24 to (self) port = http label "USER_RULE: Disallow OPT to access webGUI, SSH" block return in quick on igb2 inet proto udp from 192.168.2.0/24 to (self) port = https label "USER_RULE: Disallow OPT to access webGUI, SSH" block return in quick on igb2 inet proto udp from 192.168.2.0/24 to (self) port = ssh label "USER_RULE: Disallow OPT to access webGUI, SSH" pass in quick on igb2 inet from any to ! 192.168.1.0/24 flags S/SA keep state label "USER_RULE: 10/100Mbps LAN" -
I'm just thinking that it could be the issue caused by pfBlockerNG DNSBL Virtual IP?
pass in quick on igb2 inet from any to ! 192.168.1.0/24 flags S/SA keep state label "USER_RULE: 10/100Mbps LAN"
pass in quick on igb2 inet from any to ! 10.10.10.1 flags S/SA keep state label "USER_RULE: 10/100Mbps LAN" -
Further discuss goes to here: https://forum.pfsense.org/index.php?topic=106742.0
