Blocked by Default deny rule
Evad last edited by
I have been using pfSense for a couple of months now and I am still learning.
So, please excuse this newbie question.
After many hours searching and reading docs looking for an answer I am still stumped.
The setup is:
WAN –> dsl router
LAN subnet 10.3.15.x
LAN gateway 10.3.15.7 <--LAN TPLINK NAT-WAN--> 10.44.15.x --> wireless bridge <---- 10.44.15.x LAN
DHCP on pfSense is enabled for LAN
Aliases setup for DHCPRange 10.3.15.100-120
I have disabled the default rule "Allow LAN to Any"
IPV4* DHCPRange any-port any-gateway
There are other rules below for different machines
10.44.15.0/24 10.3.15.7 LAN
Using a machine in the DHCPRange I can access machines in the 10.44.15.0 subnet fine. However randomly; communications with a machine on the 10.44 lan stops for a few seconds and then continues. In most cases such as a remote desktop session the connection loss is long enough the application terminates.
The firewall logs show for example:
Block time LAN source=10.3.15.101:49178 Destination=10.44.15.200:97
Default deny rule IPv4 (1000000103)
So, for some reason the allow rule (IPV4* DHCPRange any-port any-gateway) doesn't match for a few seconds and then matches again allowing communications.
Could a lost packet via the wireless bridge causes the states to get out of step causing a temporary rule match failure?
Any help would be greatly appreciated.
phil.davis last edited by
You have asymmetric routing. From 10.3.15.100 to 10.44.15.42 the packet would go:
10.3.15.100->pfSense LAN IP 10.3.15.1->TPlink 10.3.15.7->client 10.44.15.42
10.44.15.42->10.44.15.1(TPlink)->10.3.15.100 (the TPlink will see that 10.3.15.100 is on a local LAN and deliver it directly, rather than sending it via pfSense LAN IP)
As a result, pfSense states only see traffic 1-way and so they time out.
Why is the TP-Link even set up like this?
Change to use it as a plain access point:
a) Plug one of the TP-Link LAN ports to you pfSense LAN switch.
b) Turn off DHCP on TP-Link (allowing WiFi devices to get DHCP from pfSense)
c) Remove the extra gateway and static route from pfSense
Evad last edited by
Thank you for responding.
The TP-link is only a router. No wifi, no dhcp. It is only a gateway.
The TP-link is connected to the pfSense lan switch.
However I believe you are correct. By enabling port mirroring on the switch port where the pfSense LAN is connected I can see via wireshark the asymmetric routing ( Missing return packets). Thank you for your help.
If I replace the dual NIC PC hardware with a check point U20 I have laying around and program one of the extra NICs to be 10.44 then it should not have asymmetric routing. Good catch….