@KOM: You were either using NAT reflection, or you had your internal DNS handing out LAN IPs (known as split DNS). thank you for your answer, i managed to get this fixed using a internal split brain DNS. much appreciate it your support.

Took PFSense out of the equation, and things did improve a bit. I've migrated from using the RG in router mode to pass-through with the WAN address MAC now being assigned the RG's IP via DHCP. So that much is working.  Throughput is still not where it ought to be.  So next step is to possibly replace my TPLink 24-port Gigabit switch with a Cisco 24-port to see if that helps. Though all of this created a new problem with my OpenVPN install no longer working, even after I changed its IP and created new certs for OpenVPN Connect.  Posted in the OpenVPN section on issues I've got there now…OpenVPN Connect will authenticate to the firewall, but then has access to nothing.

If you're pinging raw IP addresses then pfSense has nothing to do with problem unless (very unlikely though and you aren't providing enough information) there is an IP address conflict in your network and pfSense is somehow the cause of the conflict. If you're pinging DNS names then you need to look at the DNS forwarder/resolver logs on pfSense for signs of anything amiss.

Thanks,  doktornotor @johnpoz: Yes, normally you would do that at the switch however I have an unmanaged switch. I was planning to put a TAP switch but the fact that I have three NIC's already on the firewall box and pfsense has spanning capabilities, I was thinking of going that route.

Looking more closely at everything, it almost seems like you HAVE to have NAT enabled on the pfsense machine in order to direct specific addresses through the VPN or not.

As mentioned above, from the WAN side it will be pretty safe out of the box. My first step even before I connect it to a WAN or LAN would be to change the default password though.

https://doc.pfsense.org/index.php/Firewall_Rule_Basics

1 more thing, this is from the cable modem log: Mon Feb 06 14:59:54 2017 Critical (3) Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out So the cable modem had a hiccup with the comcast signal, and when the gateway (wan) handled the change, one interface (lan) was able to cope with it, but one (opt1) was not.  I fear I'm out of my league here as they're setup the same.

@webtyro: Bad pun I know. I have one lan called "home" and another called "untrusted". I know you can guess where the visiting Microsoft units are put. Hard to trust them. I run all Debian for my own use. Microsoft had a good run but I feel they have gone rogue. Post update if it shows again. Hope not though. I've seen a quality drop from nearly every big tech company there is.

Perhaps try FreeRADIUS.

Here's my network details if it helps: Network Diagram: http://prntscr.com/e58gvo Switch network config: http://prntscr.com/e58cfj Switch VLAN settings: http://prntscr.com/e58cs4 Firewall LAN interface: http://prntscr.com/e58d8y Firewall VLAN3 interface: http://prntscr.com/e58dpp LAN DHCP settings: http://prntscr.com/e58e2b VLAN3 DHCP settings: http://prntscr.com/e58eau Relevant LAN rules: http://prntscr.com/e58eth VLAN3 rules: http://prntscr.com/e58f2p

Lan Gateway: ?? LAN Gateway should be none for pfSense.  Your settings are correct.  What is the problem you are having?

What does Windows get when you bypass pfSense?

I forgot to add the even better way.  I just added it to the previous post. Using AP with vlan support and proper placed for best cover (you may need more than 1) and smart switch gives you the most flexibility in your network.