Another default deny rule same subnet/network/vlan being blocked
-
I don't understand this:
I have allow all rule on interface Home (vlan 10).
How/why is pfSense blocking devices on the same subnet/vlan?Should I enable Bypass firewall rules for traffic on the same interface?
I'm not doing any static routing.
I looked at this and I still don't understand as my flags are different:
https://forum.netgate.com/topic/36362/log-shows-tcp-fa-tcp-fpa-blocked-from-lan/4
https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html
https://forum.netgate.com/topic/132592/tcp-ra-tcp-a-tcp-pa-blocked -
@lightingman117 said in Another default deny rule same subnet/network/vlan being blocked:
Should I enable Bypass firewall rules for traffic on the same interface?
No... Your traffic is shown as out of state there.. See the A and RA is a reset..
192.168.10.137 and 192.168.10.89 would normally be in the same network (255.255.255.0 or /24) - and pfsense should never even see this traffic.. What mask are you using on this home10 network? What is the masks on the 2 IPs your seeing here. Possible you have a mask problem and vs traffic being sent direct to the client its going to pfsense, but pfsense never saw the syn to create the state.
For example if you were using a /25 mask then .137 and .89 would be on different networks.
192.168.10.0 - 192.168.10.127
192.168.10.128 - 192.168.10.255 -
I didn't think so...
.89 is my computer running PLEX
.137 is my NVIDIA Shield.89 is reserved DHCP
.137 is full DHCP.89 is hardwired to managed switch
.137 is wireless to WAPHome10 is standard 192.168.10.0/24 on vlan10
pfSense is trunked/vlan'd to a mikrotik switch
mikrotik to computer on vlan10
mikrotik to UAP-AC-Pro on vlan10 + IOT vlan -
There would be no reason for client to send that traffic to pfsense unless its mask was not /24 - all I am saying..
There would never be a reason for pfsense to ever see that traffic.. Since its seeing it - there is something wrong in your setup.
Or maybe you have pfsense with .89 address now? In a normal setup - there would be now way for pfsense to ever see that traffic because it would not be sent to its mac.. The only reason it would be sent to its mac, is the client thought the destination IP was not on its network - so it would send to its gateway (pfsense)... Or it resolve that destination IP mac to pfsense mac..
Are you doing some bridge in pfsense? Where this traffic wold flow over pfsense bridge interface? Draw up how you have everything connected?
-
I mean, I agree. But I don't see how. Both clients are DHCP and are 'working'.
Maybe the unifi AP has a trunk issue on its side config wise? But I don't see how that would cause any issues with the clients working but throwing errors?
Just saw your edit, I'll draw up a diagram.
No bridge. It's a pretty simple setup.
-
Well pfsense has no control over what traffic is sent to its mac.. But if it sees traffic and there is no state, and its not a syn, then yeah its going to be blocked.
You need to figure out why your .137 device is sending traffic to pfsense mac address.. be it thinks its a gateway, or some other device on your network would send it, but it wouldn't send it to pfsense mac.. Maybe you have your switch trying to do routing vs just L2 and its mask is wrong so its sending the traffic to pfsense?
If you have no bridging setup in pfsense - then those are the things that would explain the traffic..
I would say maybe your states got reset which is why you are seeing blocks - but that doesn't make any sense because pfsense should never see traffic that is 2 clients talking to each other on the same network.. So there would never have been a state in the first place to get reset.
edit: Check your .137 arp table - validate it shows the correct mac for .89 client.. If for whatever reason it had pfsense mac - then pfsense would see the traffic. But this might be hard on a nvidia shield device.. Had you recently changed masks on the network? Or added this network, I have shield I could look at to see what kind of info you can glean from it for info about its mask, etc. But again - pfsense should never see this traffic in the first place - you need to figure out why it is to correct the problem..
-
Welp, I have no idea what is going on.
I shored up the setup a bit more.
AP has MGT for VLAN 10, same as Home SSID which Shield is connected.
IOT is VL-110.Switch trunk is correct and enforced.
Shield is switched to static address.
Computer ipconfig looks correct.
I restarted computer & shield.
The shield (.137) is the only device this occurs on.
I turned off firewalls on desktop.
Switch is just simple L2. (Mikrotik running SWOS, CRS328-24p-4s+rm)
I looked at switch mac table and it shows only the devices in question on the correct ports.
@johnpoz said in Another default deny rule same subnet/network/vlan being blocked:
edit: Check your .137 arp table - validate it shows the correct mac for .89 client.. If for whatever reason it had pfsense mac - then pfsense would see the traffic. But this might be hard on a nvidia shield device.. Had you recently changed masks on the network? Or added this network, I have shield I could look at to see what kind of info you can glean from it for info about its mask, etc. But again - pfsense should never see this traffic in the first place - you need to figure out why it is to correct the problem..
I'll need to look up how to see arp table on the android shield.
I did look through network settings and it didn't show a mask when DHCP.
When I set it to static I was able to specify /24 and gateway.It is a brand new setup; took out UDM to replace with pfSense, switch, & AP.
Really weird thing is the darn thing works. Plex works, other apps work. It's spewing out messages to the wrong mac, but it's still working...?
