Why is this LAN traffic being blocked?
-
Are the source and destination device on the same subnet?
If so, I'd ask why the traffic passes pfSense? -
Yes, they are on the same subnet. I should already be passing all traffic in the 192.168.1.0/24 subnet without restrictions (desired behavior).
Here are the some associated filter log entries for the blocks (and one pass):
Aug 16 12:18:37 hades filterlog: 9,16777216,,1000000103,igb0,match,block,in,4,0x10,,64,0,0,DF,6,tcp,232,192.168.1.20,192.168.1.172,62774,22,180,PA,2663790651:2663790831,207159216,4096,,nop;nop;TS
Aug 16 12:18:39 hades filterlog: 9,16777216,,1000000103,igb0,match,block,in,4,0x10,,64,0,0,DF,6,tcp,232,192.168.1.20,192.168.1.172,62774,22,180,PA,2663790651:2663790831,207159216,4096,,nop;nop;TS
Aug 16 12:18:42 hades filterlog: 9,16777216,,1000000103,igb0,match,block,in,4,0x10,,64,0,0,DF,6,tcp,232,192.168.1.20,192.168.1.172,62774,22,180,PA,2663790651:2663790831,207159216,4096,,nop;nop;TS
Aug 16 12:18:49 hades filterlog: 9,16777216,,1000000103,igb0,match,block,in,4,0x10,,64,0,0,DF,6,tcp,232,192.168.1.20,192.168.1.172,62774,22,180,PA,2663790651:2663790831,207159216,4096,,nop;nop;TS
Aug 16 12:18:56 hades filterlog: 9,16777216,,1000000103,igb0,match,block,in,4,0x10,,64,0,0,DF,6,tcp,232,192.168.1.20,192.168.1.172,62774,22,180,PA,2663790651:2663790831,207159216,4096,,nop;nop;TS
Aug 16 12:19:00 hades filterlog: 89,16777216,,1534396921,igb0,match,pass,in,4,0x0,,64,0,0,DF,6,tcp,64,192.168.1.20,192.168.1.172,49800,22,0,S,2178878714,,65535,,mss;nop;wscale;nop;nop;TS;sackOK;eol
Aug 16 12:19:02 hades filterlog: 9,16777216,,1000000103,igb0,match,block,in,4,0x10,,64,0,0,DF,6,tcp,232,192.168.1.20,192.168.1.172,62774,22,180,PA,2663790651:2663790831,207159216,4096,,nop;nop;TS
Aug 16 12:19:09 hades filterlog: 9,16777216,,1000000103,igb0,match,block,in,4,0x10,,64,0,0,DF,6,tcp,232,192.168.1.20,192.168.1.172,62774,22,180,PA,2663790651:2663790831,207159216,4096,,nop;nop;TS -
Intra-network traffic doesn't hit the firewall at all. Out of state traffic is blocked since the state was already killed.
https://doc.pfsense.org/index.php/Why_do_my_logs_show_%22blocked%22_for_traffic_from_a_legitimate_connection
-
But why is the traffic directed to pfSense, when the source and destination is in the same network segment?
Have you bridged interfaces, so the the source is on one interface and the dest on the other one?
Or miss-configured the network in on device.
Or are there multiple ways the traffic can go between source and dest? -
Unless your running a bridge and you have these devices on different sides of the bridge - pfsense should never see this traffic unless you have mask on these devices higher than /24 so they are on different networks?
-
The 192.168.1.172 host also has an interface on the WAN (independent of pfsense) and has a different default gateway (other than the lan), like the rest of the . The host is actually freepbx.
-
So you have a "mess" Why don't you draw this network up so we can figure out how to fix your asymmetrical mess.
Multihoming devices, is almost never a good idea and leads to complications unless you are sure of traffic flow. For example if devices uses say interface 1 to talk to B, but B answers back to interface 2 on their common network.
I would really suggest you rethink the need for multihoming said device.
-
Will definitely do so. At the office. Look for it in a few hours. Thanks
-
Ok, here you go.
-
Nice drawing thanks!
And why can this freepbx just not be behind your pfsense on the 192.168.1.0/24 with just the 1 192.168.1.172 address?
2 second google finds what looks to be very simple instructions for putting it behind pfsense
https://www.outsideopen.com/pfsense-asterisk/Clearly your not worried about it being on your lan since you have it directly connected now. But I would prob put it on a different vlan say 192.168.2/24.. Then just create what firewall rules you need between lan and this new "dmz" lets call it for your stuff to work, there is no nat between lan and dmz..
-
I've decided to change my deployment model to be behind the NAT with 1:1 NAT. So far, testing is proving successful. Would be great to make the dual-homed model work, but I'm afraid it may be more trouble than it's worth.
Thank you for your attention on this.
