Traffic between LANs blocked despite firewall rules allowing it.

jhboricua

I'm at the end of the rope and getting way too many calls from a client for weird connectivity issues. I installed an ALIX based pfsense box on their office. In a nutshell, the problem is that traffic from the wireless interface is being blocked by pfsense even though the firewall rules are set to allow it. It's driving me nuts so I need to some help to keep my sanity.

First I tried to bridge the wireless interface to the lan interface but the firewall was blocking traffic from the wireless to the lan even though there was a allow all rule (the denied traffic was shown on the logs). Traffic being denied among others was DHCP traffic (clients could not get an IP address) DNS udp 53 traffic to the DNS server on the LAN, etc.

So I gave up on bridging and set the wireless interface on its own class c network. I then set the rules to allow any traffic from wireless to lan, and 2 other rules allowing any http and https traffic from the wireless. The idea is for the wireless users to have open access to the LAN Network but only HTTP and HTTPS access to the internet.

Despite these rules, users are still having problems with name resolution and I can see the pfsense firewall logs denying traffic from the wireless network to the lan network.

The setup: Alix 2d3 pfsense box runing 1.2.3-RELEASE

Interfaces:
WAN- PPPoE to AT&T Uverse DSL
LAN- 192.168.200.0/24
Wireless- 192.168.201.0/24

Firewall Rules

LAN interface:

Wireless interface:

| Proto | Source | Port | Destination | Port | Gateway | Schedule | Description |
| * | Wireless Net | * | LAN Net | * | * | | Wireless -> LAN |
| * | Wireless Net | * | * | 80 | * | | HTTP -> Any |
| * | Wireless Net | * | * | 443 | * | | HTTPS -> Any |

When I click on the log entry for the denied traffic it says its being denied by: @103 block drop in log quick all label "Default deny rule"

What is this rule? Why is it overriding the allow rule? Can someone tell me what am I doing wrong?

jhboricua

Not sure why the tables with the interface rules are not showing correctly. Highlighting the area should reveal the table. I guess its not my day today.

But just in case:

LAN interface:


Proto	Source		Port		Destination	Port		Gateway		Schedule		Description
*		LAN Net		*		*			*		*			n/a			Default LAN -> Any

Wireless Interface:


Proto	Source		Port		Destination	Port		Gateway		Schedule		Description
*		Wireless Net	*		LAN Net		*		*			n/a			Wireless -> LAN
*		Wireless Net	*		*			80		*			n/a			HTTP -> Any
*		Wireless Net	*		*			443		*			n/a			HTTPS -> Any

cmb

What exactly do the logs for the denied traffic look like?

jhboricua

Hi CMB,

Here's what the typical deny entry looks like from yesterday.


Act	Time				If 			Source 				Destination 			Proto
X	Feb 10 13:45:09 	Wireless 		192.168.201.122:3645 	192.168.200.10:53 		UDP

Because of the above, users were unable to browse the internet or internal resources that depended on DNS resolution.

I had to take out the rules on the wireless interface last night because I couldn't keep this issue affecting the wireless users at my client's site any longer. They were replace by the standard allow all rule until I can hash out what is the issue. I still need to lock down the internet traffic originating from the wireless users to only http and https while allowing any traffic to the internal LAN, just like the rules on my opening post. I'm not sure if the rules are wrong because to me they look ok.

Guest

Under Interfaces > Wireless (whichever it is named opt1 normally), make sure that the "block private networks" isn't checked.

But if I understand what you're saying, when you remove the allow rules for port 80/443 on the wifi interface, then they are able to access the LAN? What if you modify the rule on the wifi interface from Destination: Lan Net, to the actual IP range like 192.168.200.1/24? I understand by choosing Lan NET, this should do this, but it can't hurt to try?

@jhboricua:

Hi CMB,

Here's what the typical deny entry looks like from yesterday.
Act	Time				If 			Source 				Destination 			Proto
X	Feb 10 13:45:09 	Wireless 		192.168.201.122:3645 	192.168.200.10:53 		UDP
Because of the above, users were unable to browse the internet or internal resources that depended on DNS resolution.

I had to take out the rules on the wireless interface last night because I couldn't keep this issue affecting the wireless users at my client's site any longer. They were replace by the standard allow all rule until I can hash out what is the issue. I still need to lock down the internet traffic originating from the wireless users to only http and https while allowing any traffic to the internal LAN, just like the rules on my opening post. I'm not sure if the rules are wrong because to me they look ok.