Need help on weird firewall behavior
-
I'm pretty new to pfsense. currently running 2.4.5-RELEASE-p1 version in a esxi virtual machine. Everything is fine except the following weird firewall behavior:
I have two vlans:
UNTRUSTEDIOT: vlan tag 9, ip 192.168.2.1
GUEST: vlan tag 11, ip 192.168.3.1All the devices in UNTRUSTEDIOT are fine, get correct IP though DHCP, can access other subnet or internet if firewall rule allow, or can be blocked with corresponding firewall rule.
The problem is for the other vlan GUEST. the devices can get right IP though DHCP. I set to pass all traffic, but most of time, the devices can't access internet or other subnet (sometimes it can). when the traffic is blocked, I got the following log:
The weird thing is the log shows the right IP (192.168.3.2) of the device in vlan GUEST, but the interface is UNTRUSTEDIOT (which should be the subnet of 192.168.2.1). And I can't recognize or find what is the rule of 1000008920.
-
It should be impossible for you to see traffic on your untrusted interface from your guest vlan.
You have a problem with your L2 isolation.. Or wrong tag on the traffic.
Do you not have rule descriptions listed in your firewall log, this is setting. But you can always find the rule via its ID with
https://docs.netgate.com/pfsense/en/latest/firewall/pf-ruleset.html
-
@johnpoz said in Need help on weird firewall behavior:
https://docs.netgate.com/pfsense/en/latest/firewall/pf-ruleset.html
I use an asus RT-AC68U working in AP mode. I put different tag on two SSID. Probably I did it wrong, do you have any idea if there is problem with the following script running on asus:
robocfg vlans reset vlan 1 ports "0 2 3 4 5t" vlan 9 ports "0t 2t 5t" vlan 11 ports "0t 2t 5t" vconfig add eth0 9 ifconfig vlan9 up vconfig add eth0 11 ifconfig vlan11 up brctl delif br0 wl0.1 brctl delif br0 wl1.1 brctl addbr br1 brctl addif br1 wl0.1 brctl addif br1 vlan9 ifconfig br1 up brctl addbr br2 brctl addif br2 wl1.1 brctl addif br2 vlan11 ifconfig br2 up nvram set lan_ifnames="vlan1 eth1 eth2" nvram set lan_ifname="br0" nvram set lan1_ifnames="vlan3 wl0.1" nvram set lan1_ifname="br1" nvram set lan2_ifnames="vlan13 wl1.1" nvram set lan2_ifname="br2" killall eapd eapd
-
@johnpoz
/tmp/rules.debug shows the 1000008920 is a antispoof rule. But I have no idea what does that mean. -
@uioi
I made a mistake, this is the right script running in asus RT-AC68Urobocfg vlans reset vlan 1 ports "0 2 3 4 5t" vlan 9 ports "0t 2t 5t" vlan 11 ports "0t 2t 5t" vconfig add eth0 9 ifconfig vlan9 up vconfig add eth0 11 ifconfig vlan11 up brctl delif br0 wl0.1 brctl delif br0 wl1.1 brctl addbr br1 brctl addif br1 wl0.1 brctl addif br1 vlan9 ifconfig br1 up brctl addbr br2 brctl addif br2 wl1.1 brctl addif br2 vlan11 ifconfig br2 up nvram set lan_ifnames="vlan1 eth1 eth2" nvram set lan_ifname="br0" nvram set lan1_ifnames="vlan9 wl0.1" nvram set lan1_ifname="br1" nvram set lan2_ifnames="vlan11 wl1.1" nvram set lan2_ifname="br2" killall eapd eapd
-
You have something wrong.. It would not be possible for interface A to see traffic from network B if your actually isolating your L2 correctly..
Your AP is not tagging the traffic correctly would be logical reason for this.
https://docs.netgate.com/pfsense/en/latest/firewall/rule-methodology.html#anti-spoofing-rules
Anti-spoofing Rules
pfSense uses the antispoof feature in pf to block spoofed traffic. This provides Unicast Reverse Path Forwarding (uRPF) functionality as defined in RFC 3704. The firewall checks each packet against its routing table, and if a connection attempt comes from a source IP address on an interface where the firewall knows that network does not reside, it is dropped. For example, a packet coming in WAN with a source IP address of an internal network is dropped. Anything initiated on the internal network with a source IP address that does not reside on the internal network is dropped.
-
@johnpoz said in Need help on weird firewall behavior:
https://docs.netgate.com/pfsense/en/latest/firewall/rule-methodology.html#anti-spoofing-rules
That makes sense. I'll look into the tagging on the AP. Thank you.