@johnpoz Sorry - should have been more clear (and I'm still learning how/where pfSense falls into place here, in terms of its initial configuration). I was thinking about more 'foundational" features, such as as a DHCP server, DNS, toughening up security with some simple rules, etc, etc. But your last comment clarifies things, I think. It seems I can simply drop pfSense between my modem and ASUS router and use double NAT. The default configuration you describe sounds exactly as I'd want (and allow my existing devices to continue "blissfully unaware"). The only thing I'd need initially is OpenVPN, since I regularly remote into desktops from coffee shops over RDP (and don't plan on forwarding ports), etc. With VPN installed and configured, I'd be pretty much at parity with what I have now and can then start walking down the path of leveraging pfSense to the full, particularly as I implement IOT isolation across a couple of subnets. Thank you again, @johnpoz .

@T-Soprano Rule of thumb, always suspect cables and connectors. I have a simple continuity tester, which I carry in my computer bag, just for testing cables at customer sites. This is just a simple go/no go test, not performance certification.

@statecowboy said in Problems with PIA-VPN Interface: Dec 13 06:10:30 openvpn 23211 ERROR: FreeBSD route delete command failed: external program exited with error status: 1 That log implies the OpenVPN daemon is trying to modify the routing table and failed. You might have some routing conflict there with something OpenVPN is trying to use. Steve

Yes, it could be something else causing the drive write to fail mid-write. Bad SSD. Bad internal power. Bad cable. I have seen bad SATA cables do some truly weird stuff, I would swap that out first if you have not already. Steve

Yes, that 165.x.x.x public IP does not appear in the routing table so you are behind the NAT of that cellular router. You will need a port forward in place for that in the cellular router if you cannot pass the public IP to pfSense directly. You can see on the WAN firewall rules that 0 packets and states have been passed by the UDP 1194 rules. No traffic from the client is reaching pfSense currently. Steve

bolo, please let me now which script did you add. Thanks in advance.

NAT type 2? or are you double NATtd?

@Mr_AJ I haven't given the matter thought since. Turning off the TLS check solved the problem. The risk of a bad actor causing an attack, presumably through man in the middle, doesn't concern me. If there's a reason I should be concerned, I'd appreciate learning of it.

Good info, I'll have to try this tonight.

I'm having this same issue with the Intel PRO/1000 MT Desktop Adapter .. never had an issue with these nics in our DC's before ... I've also tried different PCI ports to no avail UPDATE: it seemed as if my NIC card was completely dead. nothing to do with pfsense

Tested the issue further, added another ethernet card and guess what worked flawless with dhcp getting picked up, tried it many times and it and I don't need to add any Reject leases from 192.168.100.1 entry. Maybe pfsense just hates my onboard ethernet ports, either way issue sorted.

@shooters running into the same problem. Were you able to hunt down a solution?

@stephenw10 thank for your reply

All, Thank you for your responses. After trying various things you suggested i figured something wasn't right - i removed all my rules to default and FTP connection worked right away. I do not know why FTP didn't work yet other things from LAN->WAN did but i guess i will learn these next few months. Appreciate the support - thank you Jon

Do you have any IPv6 connectivity? Some partial v6 connection can cause massive issues as things have to timeout v6 if it's broken before falling back to v4.

Perfect, thanks for the info. I'll look around online for more details

Hmm, GRE tunnel to where? Between the amplifi nodes? To some cloud location? More info needed there. Not really sure how that might be used, though it probably could be.... Steve