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

    Port forward appears blocked by outbound default deny rule...80, 443

    Scheduled Pinned Locked Moved General pfSense Questions
    3 Posts 1 Posters 485 Views
    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.
    • N
      netgr8
      last edited by netgr8

      Any help would be much appreciated.

      Responses from the internal webserver, 192.168.30.17, appear blocked by the default outbound rule. wan_to_websvr.png
      The source in the screenshot is my WAN public IP. I'd think it would be the webserver's local IP though. Packet capture from WAN (internet)-initiated requests time out and pcap shows lots of retransmissions by the webserver's local IP. Makes me think there's a NAT issue.
      Outbound NAT is Int WAN | Src 192.168.30.0/24 ...any... | NAT address WAN address. Internal networks reach the webserver without issue (http requests are redirected to 443 by the webhost's nginx).

      Port Forward:
      Int WAN | Protocol TCP | Dst WAN | Dst range TCP 80 and 443 | Target IP 192.168.30.17 | Target port TCP 80 and 443 | NAT Reflection: Sys default | Filter rule association: Rule NAT
      NAT_port forward.PNG

      Rules_port foward.PNG

      System > Advanced > Firewall & NAT:
      NAT Reflection mode for port forwards = Pure NAT
      Enable automatic outbound NAT for Reflection = Enabled

      System > Advanced > Admin Access = HTTPS on custom port (not 443), WebGUI redirect is checked, to disable the redirect (I think this is needed to make TCP 80 available?)

      Firewall > Outbound NAT Mode = Hybrid Outbound NAT rule generation.
      Firewall > Rules for Webserver Interface (mvneta0.30) = Bottom rule is allow all through WAN Gateway (disabled rules above it in testing)

      Info from Shell:

      NAT Inbound Redirects

      rdr on mvneta0.4090 inet proto tcp from any to "WAN_IP" port $80_443 -> 192.168.30.17

      Reflection redirect

      rdr on { mvneta0.4091 mvneta0.4092 mvneta0.28 mvneta0.29 mvneta0.30 mvneta0.31 openvpn } inet proto tcp from any to "WAN_IP" port $80_443 -> 192.168.30.17
      no nat on mvneta0.30 proto tcp from (mvneta0.30) to 192.168.30.17
      nat on mvneta0.30 proto tcp from 192.168.30.0/24 to 192.168.30.17 -> 192.168.30.1 port 1024:65535
      #---------------------------------------------------------------------------

      default deny rules

      #---------------------------------------------------------------------------
      block in log inet all tracker 1000000103 label "Default deny rule IPv4"
      block out log inet all tracker 1000000104 label "Default deny rule IPv4"

      N 1 Reply Last reply Reply Quote 0
      • N
        netgr8 @netgr8
        last edited by netgr8

        @netgr8

        Ok, so this works as intended unless an oVPN client connection, configured on the fw, is up. There are internal IPs configured in NAT and Rules to send them through that interface (webserver not included), rather than the WAN interface. Webserver is configured to use the WAN interface. GW Monitoring and action for oVPN seem to have no bearing on the result.

        Glad to have this narrowed down a bit. I'll continue troubleshooting.

        N 1 Reply Last reply Reply Quote 0
        • N
          netgr8 @netgr8
          last edited by

          The port forward was failing due to a routing issue caused by the oVPN client connection. The baseline config documented by the provider had not mentioned that it would pull routes for the below and I hadn't noticed:
          0.0.0.0/1, 128.0.0.0/1, 2000::/3

          I had masked the issue by explicitly defining the gateway used by outbound Rules. Once the option "Don't pull routes" was enabled in the oVPN client config, the port forward was happy and the gateway no longer needed defining in Rules. I've requested of the oVPN provider, PIA, to include this as a heads up in their guide....and now I am more aware of the routes.

          The webserver's response now shows as expected from the internal interface.
          outbound.png

          Thanks to @its_maek for documenting their findings in this netgate forum topic!

          VPN Server from Private Internet Access (PIA) created a route 0.0.0.0/1 when the interface is created.
          
          In OpenVPN client I had to select "Don't pull routes" and it no longer makes that route. pfSense 127.0.0.1 now properly goes through the default Gateway.
          
          1 Reply Last reply Reply Quote 1
          • First post
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.