well patience wasnt a virtue here, reloaded and back to normal for now. Just need to figure out exactly what i did to gum and since i am not taking backups yet since i am still learning this has been a good experience reconfiguring everything :-). Glass half full for sure….....

@Tantamount & @johnpoz: Thank you for responding! Tantamount, your response is very helpful. I have responded to your observation and advice below. Please tell me if I am on the right track: –------------ It looks like you've got two internal networks -- one for regular internet traffic (ISP) and one for VPN traffic (VPN).  Each has its own subnet.  I assume you use different SSID's and have to manually change between these depending on what your want your lan devices to use -- in other words you want the networks isolated from each other. So now you want to make pfsense be your first line of defense. Absolutely correct – that is exactly how I want to setup Start by making sure that the dhcp server on the pfsense is using the same subnet as (ISP).  Then for the (ISP) wifi router, configure it to dumb AP mode.  That should mirror your current setup -- lan devices would get ip addresses in the subnet they're familiar with, and you only have one nat translation occurring -- except now it's happening at pfsense and not the (ISP) router. In my current setup (Fios via Ethernet), I do not have any ISP supplied equipment. I connect one of my Cellspot (Asus) routers directly to the Ethernet cable. Ethernet from Fios ONT comes in directly to the WAN port of Router 1. So as I understand: Connect the incoming Ethernet to the WAN port of psSense box. Then change Router 1 to AP mode. From pfSense LAN port, connect AP (LAN to WAN?) Change pfSense LAN to 192.168.1.1 (Do I need to change AP to 192.168.1.2 or let psS DHCP handle that?) This just leaves the (VPN) router and that network.  Plugging the wan port of (VPN) into the lan side of pfsense should work the same as how you originally had things before pfsense was added.  Traffic coming into the LAN or wifi side of (VPN) would go through the VPN tunnel.  This tunnel is natted first from the (VPN) router to lan pfsense, and then natted again from lan pfsense to wan pfsense. pfsense shouldn't be causing any issues with this. As far as it knows, a single device on the lan network (VPN router) is trying to connect to something on the internet. I tried this past weekend however I think I could not get the OPT1 (2nd LAN port in pfSense box) configured correctly so I was getting no packets. Do I need to configure any rules? I copied the ipv4 connectivity rule from LAN to OPT1 but still couldn’t get connection I create a second subnet : 192.168.2.1 on OPT1  - Do I let pfSense DHCP handle the VPN Router? Or should I configure it to 192.168.2.2 ? Did I get the above correct? If not, please correct me. (Thanks!). If I missed stuff, please feel free to add it in. As johnpoz mentioned however, this is making things more complex then it needs to be. Ideally what you'd want to do is configure openvpn to work with AirVPN in pfsense.  Then have all internal vpn traffic go through a second LAN port of pfsense out to the other (VPN) router -- now in AP mode. This is what I ideally wanted, and perhaps once I am more confident of my abilities, I will attempt it. I did I quick search for AirVPN and it looks like there are all kinds of instructions for getting it working with various equipment, such as dd-wrt (Another router similar to pfsense).  If you cannot translate these instructions for pfsense, I suggest looking to see if AirVPN has a forum where you can get the help you need because this is definitely doable. You'll almost certainly get better performance this way due to the better hardware running pfsense vs that wifi router. Here is a link to a very comprehensive guide that I found on the airvpn forum for psSense 2.3 (https://airvpn.org/topic/17444-how-to-set-up-pfsense-23-for-airvpn/ ), however I think, at this time it’s a bigger bite than I can chew. Unfortunately I cannot have my network down for over an hour, and this isn’t something that I am confident of being able to achieve within that time…

If I connect via the VPN and then SSH to one of the new servers (e.g. the .145 one), then once I'm logged in there I am able to ping all of the other assigned /26 addresses.  So I can ping 68.0.0.129 (the gateway), 68.0.0.130 (live server), 68.0.0.140 (the other server that I can't reach from outside), all of those work.  So the IP is getting bound to the correct server, but it's not routable.  I tried to ping an unassigned IP in the /26 network and it was not reachable, so it's not that all of the IPs are responding by something like pfSense, only the assigned IPs are responding.

A follow up: There was indeed a baud rate mismatch when transitioning from BIOS boot messages to kernel boot messages.  But in my defense, the presence of that mismatch seemed to make the kernel "want" a carriage return to continue to load.  So yes, it's possible that loading a config file that causes that console baud rate mismatch can cause the system to hang.  YMMV of course.

I didn't  find a way to reset the WAN-IP from the developershell without a reboot. If anyone knows i'd like to hear about a solution without a reboot. My developer-shell solution looks like this $config['interfaces']['wan']['disabled'] = false; $config['interfaces']['wan']['ipaddr'] = "<ip>"; $config['interfaces']['wan']['subnet'] = "<subnet>"; $config['gateways']['gateway_item'][0]['gateway'] = "<gw>"; $config['gateways']['gateway_item'][0]['name'] = "GW_WAN"; $config['gateways']['gateway_item'][0]['interface'] = "wan"; $config['gateways']['gateway_item'][0]['monitor_disable'] = true; $config['gateways']['gateway_item'][0]['defaultgw'] = true; write_config(); exec; system_reboot_sync(); exec;</gw></subnet></ip> exit  <- Systems reboot, is not executed

They are not pinging your modem from 8.8.8.8. Traceroute out and, when you see packet loss to 8.8.8.8 ping something closer. If you can reliably see loss to something closer - preferably within your ISP's own network - try complaining about that. Squeaky wheel gets the grease, as they say. Now just to say we have this same version of pfsense running at my office with the same provider only difference is at my house it is a slower connection so any help would be appreciated. Are you moving traffic anywhere close to what the ISP says you should be able to do during these periods of ICMP packet loss?

finally found solution for the ARP problem, nothing with pfSesne but the vmware. Simpy set promiscuous mode on for vSwitch will solve this. Reference : http://unix.stackexchange.com/questions/23004/openvpn-bridge-cant-access-machines-on-local-network

Thanks everyone. Appreciate the feedback.

No, because for security reasons it has to report every attempted connection. The alternative would be someone/something nefarious hitting the port and you'd never know.

is theire any configuration to add to the pfsense firewall or some NAT to do or Forwarding Rules? By default, only LAN gets a firewall rule to allow access.  OPT1 does not, so you will likely need to add at least one rule.  Look at your LAN rules and find the one labelled Default allow LAN to any.  Make a rule exactly like this one but on the OPT1 interface instead of LAN.

2FA is already what you have.. You have the cert and a username and password if you want it, that is 2FA..  How many factors do you need?  I think we should put in a dna test before you get on..

I don't need to do that.. But my mtu on my gif to HE is set to 1480 mtu gif0: flags=8051 <up,pointopoint,running,multicast>metric 0 mtu 1480</up,pointopoint,running,multicast>

just a wild thought this might be a nice add to pfblockerng or both ids/ips packages

Well, the WAN interfaces on each pfsense HA-node does not share a virtual IP, so there is no seamless failover of sessions between the HA nodes, if one node goes down, the backup node will take over, but all state/sessions are lost and needs to be re-initialized. like you said, in order for this to be done correctly one would have to have some control over the upstream hardware (which I don't).