Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Firewall blocking between subnets - Makes no sense

    Firewalling
    3
    6
    1.8k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      smk
      last edited by

      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)

      1 Reply Last reply Reply Quote 0
      • DerelictD
        Derelict LAYER 8 Netgate
        last edited by

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

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 0
        • S
          smk
          last edited by

          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

          1 Reply Last reply Reply Quote 0
          • DerelictD
            Derelict LAYER 8 Netgate
            last edited by

            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.

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

            1 Reply Last reply Reply Quote 0
            • H
              Harvy66
              last edited by

              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?

              1 Reply Last reply Reply Quote 0
              • S
                smk
                last edited by

                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!

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.