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

netgr8

Any help would be much appreciated.

Responses from the internal webserver, 192.168.30.17, appear blocked by the default outbound rule.
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).

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"

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.

netgr8

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.

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.