OpenVPN on pfSense behind ISP router

Hi Sean,

Thanks for your response. I ran a few nmap tests and have concluded the FIOS router is not blocking traffic to pfSense.

nmap testing FROM Family Network (Red network on the diagram in the first post) TO pfsense (blue network)

macbook:~ charles$ nmap 192.168.1.8
Starting Nmap 7.91 ( https://nmap.org ) at 2020-12-16 13:38 EST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.12 seconds

First test shows that pfSense may be down. I know it is not down so I will attempt using the -Pn flag as nmap suggests.

macbook:~ charles$ nmap -Pn 192.168.1.8
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower.
Starting Nmap 7.91 ( https://nmap.org ) at 2020-12-16 13:40 EST
Nmap scan report for pfSense.fios-router.home (192.168.1.8)
Host is up.
All 1000 scanned ports on pfSense.fios-router.home (192.168.1.8) are filtered

Nmap done: 1 IP address (1 host up) scanned in 402.95 seconds

While running the above test, I looked at the pfSense logs. Specifically: Status/System Logs / Firewall
I was able to see tons of firewall log entries originating from the laptop running nmap. pfSense is denying/blocking/ these pings. So it looks like traffic originating from the “Family Network” is reaching the pfSense firewall and then being blocked by pfSense. This was not my original hypothesis.

It looks like my problem is that the pfSense firewall is blocking the attempted VPN connections into the OpenVPN service on pfSense. In the firewall logs I found the entry that is blocking the attempted OpenVPN connection. The error message (click on red X icon in leftmost column of log) reads as follows:

The rule that triggered this action is:
@5(1000000103) block drop in log inet all label “Default deny rule IPv4”

When I setup the OpenVPN in pfSense using the built-in wizard, it auto configured the Firewall Rule and OpenVPN rule. It looks like the default firewall rule is blocking the connection despite the wizard creating a WAN rule to permit such a connection. Back to further research, thank you for the nmap pointers - you’ve helped me to the next step, hoping to document my process here in case someone else comes along the same problem in the future.