Derelict, your instructions resolved our routing troubles perfectly! Thank you so much for responding to my problem! Bonte

Why do you have a second pfSense in your VPC? This is not necessary and as far as I know, AWS just supports IPsec with IKEv1. I basically covered what you want to do in a post a few days ago: https://www.ceos3c.com/2017/04/24/site-to-site-vpn-between-pfsense-and-aws-vpc/ Maybe this can help you? You over complicate things with the second virtual pfSense inside of AWS in my opinion. AWS has more than enough security measures in place that this is not needed. Ceo

I'm a dunce, plain and simple…. deleted everything again, no crazy port number etc.  what I was doing wrong was the wrong android client during the export... was choosing openvpn connect and using a similarly named app in the google play store... realized this when I went back to square 0 and deleted everything off every device I had tried... realized the interface was different and noticed i was using two different apps. needless to say, it works now.  icon in the play store is even the same..... OpenVPN Connect vs OpenVPN Connect for Android (two diff companies) TLDR; read, re-read instructions, follow names explicitly.

Would think your old sysadmin was an idiot ;)

thanx, i needed this

No, it's always been around 75ms. We have a roadwarrior in Site4 that ALWAYS had this issue with pulling files from Site1, so months ago I configured a separate openVPN server at Site1 for them using TCP and a different port. I just switched Site2 to use the TCP openVPN server and now I can pull large files without issue, albeit much slower then UDP. Just can't figure out why this Site2 UDP problem started now, but it seems to be latency induced.?.?

OpenVPN is more flexible in routing, NAT, etc. IPsec generally performs better at higher speeds. Both will securely transport multiple subnets to and from the mothership.

Problem solved / workaround… I had been using the setting to store the key in the Windows Certificate Manager, instead of local files. This seems to work on PCs where the local user is in the domain, but not when the user is logged on with a local account. I changed the settings in the package manager on the pfSense to just use local files and et voilá it connected first time! So there seems to be some problem with the way that the Windows Certificate Manager and OpenVPN are interacting, when local account name doesn't match the VPN login (we use RADIUS on the pfSense to authenticate users). Once the name matches, the error about the exired certifivate goes away, but it still can't connect (server log says that the key was not transmitted / "TLS Error: cannot locate HMAC in incoming packet from [AF_INET]". Once OpenVPN is configured to use local certificate files, instead of the Windows Certificate Manager, there are no errors and OpenVPN can connect without problem. Not 100% ideal, but at least we can move forward with implementing pfSense now.

Bump…does no one have any ideas here?  Surely this is possible right? :)

Thanks for clarification. That's what I am currently doing killing OpenVPN connection manually from pfsense firewall. But was seeking some auto mechanism that you clarified there is no way for OpenVPN.

After playing around with way too many settings, I finally discovered the solution: 1. Go to System/Advanced/Networking 2. UNCHECK -> Allow IPv6 [  ] All IPv6 traffic will be blocked by the firewall unless this box is checked 3. REBOOT If you don't reboot the changes won't go through for this setting. I'm still shaky on most of this stuff, so I'll leave it to someone else to educate me and others why this worked. P.S. To verify it was this setting I did the following: 1. Reboot pfsense + phone with Allow IPv6 setting CHECKED 2. Verify YouTube app is closed on phone (swipe it away) 3. Open YouTube app, and verify it's taking 10+ seconds to load the main page 4. Change the allow IPv6 setting to UNCHECKED 5. Reboot pfsense + phone 6. Repeat steps 2 and 3, except instead of 10+ seconds it should be a few seconds

@ftass: Did some debugging, haven't really had any impact since the vpn connection has worked even though the gui states not running. It is apparantly the management socket for openvpn (client 5 for me) that refuses connections. [2.1.2-RELEASE][root@pfsense-1.basement2.int]/var/etc/openvpn(24): cat client5.sock cat: client5.sock: Connection refused [2.1.2-RELEASE][root@pfsense-1.basement2.int]/var/etc/openvpn(25): cat client6.sock INFO:OpenVPN Management Interface Version 1 – type 'help' for more info I tried stopping openvpn using the gui but since it seems to be using the management socket for shutting down the client as well this wasn't working. I killed the client manually over ssh and after restarting it everything worked as intended. Seems like openvpn sometimes failes to create the management socket? I think the gui should report failure to shut down the openvpn client if the management socket isn't reachable. Could you elaborate on how you killed the client manually over ssh. I am trying to kill the process as other guys are suggesting using ps aux | grep openvpn and then killing it with kill -9 PIDnumber but it always comes back with "No such process". Thanks for the help