Firewall blocking between subnets - Makes no sense

smk · May 29, 2017, 8:32 PM

Hi

I'm relatively new to Firewall setup within pfsense. I just got my gold subscription and read through the firewall chapters but need help with this situation.

Question:
I am not able to access an IP (192.168.2.20) from a different subnet. Why? I am however able to access that IP from within the same subnet. Why is pfSense blocking when it has no reason to?

Context
PfSense 2.3.4 setup with

em 1 connect to the LAN with subnet range: 192.168.1.x
em 2 connect to a Wireless AP with subnet range: 192.168.2.x

The Wireless AP has NAT'ing turned off. DHCP performed by pfsense only.

Under "Services –> DHCP Static Mappings" I have an 192.168.2.20 assigned to a device that runs a web server on port 80.

Under Firewall --> Rules (LAN), I have the default LAN to any rule:

States Protocol Source Port Destination Port Gateway Queue Schedule Description Actions
7 /61.70 MiB * * * LAN Address 443/80 * * Anti-Lockout Rule
95 /1.19 GiB IPv4* LAN net * * * * none Default allow LAN to any rule
0 /0 B IPv6* LAN net * * * * none Default allow LAN IPv6 to any rule

Yet, when I attempted to connect from the LAN subnet on em1 to the wireless subnet on em2:
# curl -v http://192.168.2.20/cgi-bin/status
* Trying 192.168.2.20…

Connected to 192.168.2.20 (192.168.2.20) port 80 (#0)

GET /cgi-bin/status HTTP/1.1
Host: 192.168.2.20
User-Agent: curl/7.47.0
Accept: /

Empty reply from server
Connection #0 to host 192.168.2.20 left intact
curl: (52) Empty reply from server

However, I am able to connect if I initiate from within the Wireless subnet (em2).

TCP dump attached.

Under Status –> System Logs --> Firewall
May 29 13:24:21 LAN 192.168.1.175:45682 192.168.2.10:80 TCP:S
May 29 13:24:28 LAN 192.168.1.175:33938 192.168.2.20:80 TCP:S

Under Diagnostics –> States
LAN tcp 192.168.1.175:33940 -> 192.168.2.20:80 ESTABLISHED:ESTABLISHED 8 / 1 964 B / 60 B
WIRELESS tcp 192.168.1.175:33940 -> 192.168.2.20:80 ESTABLISHED:ESTABLISHED 8 / 1 964 B / 60 B

It seems to me like the firewall is allowing the forward connection from the client (192.168.1.175) to the device (192.168.2.20), but blocking the response. Is that right?

Question: Why is pfsense blocking access between the subnets ?

Best Regards

SMK
[FW 3.0.4.20 - no outside subnet access.txt](/public/imported_attachments/1/FW 3.0.4.20 - no outside subnet access.txt)

Derelict · May 29, 2017, 8:32 PM

It's not. You are getting connected just fine. Check the web server logs.

smk · May 29, 2017, 9:03 PM

Thank you for the prompt response.

I don't think its the web server on the device because it works when I remove the DHCP Static Mappings and let DHCP assign IP. This is very weird and I don't understand why.

DHCP assignment logs:
May 29 13:19:19 dhcpd uid lease 192.168.2.156 for client 34:ce:00:d5:e2:20 is duplicate on 192.168.2.0/24
May 29 13:19:19 dhcpd DHCPDISCOVER from 34:ce:00:d5:e2:20 via em2
May 29 13:19:19 dhcpd DHCPOFFER on 192.168.2.20 to 34:ce:00:d5:e2:20 via em2
May 29 13:19:19 dhcpd uid lease 192.168.2.156 for client 34:ce:00:d5:e2:20 is duplicate on 192.168.2.0/24
May 29 13:19:19 dhcpd DHCPREQUEST for 192.168.2.20 (192.168.2.1) from 34:ce:00:d5:e2:20 via em2
May 29 13:19:19 dhcpd DHCPACK on 192.168.2.20 to 34:ce:00:d5:e2:20 via em2

192.168.2.20 –> Assigned IP via Services/DHCP Server --> Does not work.
192.168.2.156 --> Self brokered IP --> Works!

What am I missing?

Best Regards

SMK

Derelict · May 29, 2017, 9:49 PM

Firewall does not care if the destination address is DHCP or not. Maybe something on the server cares.

You are connecting through the firewall and completing the TCP handshake.

* Trying 192.168.2.20…

Connected to 192.168.2.20 (192.168.2.20) port 80 (#0)

It's not the firewall.

Harvy66 · May 30, 2017, 3:20 PM

Under Diagnostics –> States
LAN tcp 192.168.1.175:33940 -> 192.168.2.20:80 ESTABLISHED:ESTABLISHED 8 / 1 964 B / 60 B
WIRELESS tcp 192.168.1.175:33940 -> 192.168.2.20:80 ESTABLISHED:ESTABLISHED 8 / 1 964 B / 60 B

This indicates that the connection is successfully created. In order for it to be "established", the full 3-way handshake must happen.

The "empty reply" you're getting is at the HTTP level, not TCP. Empty is valid. At the network level, everything seems to be working. You would not even get an empty HTTP response if there was a network issue. Any corruption of the transmission at the network level would cause the connection to fail in some catastrophic fashion like a timeout error, connection reset, or something. pfSense isn't doing some MITM and manipulating the HTTP response to claim it's empty. Unless you have Squid setup. Do you have Squid installed on pfSense?

smk · May 30, 2017, 4:23 PM

Hello Derelict & Harvy66

You have provided great responses. It makes perfect sense. Thank you for taking the time. May consider this issue closed.

@Harvy66: I do not have squid installed. I will install squid and teach myself how to use.

This is a great forum with really nice people!