Under Windows some route is missing From VPN / OpenVPN / Client Export Utility (when the client export package is installed) Management Interface Use the OpenVPNManager Management Interface. This will activate management interface in the generated .ovpn configuration and include the OpenVPNManager program in the Windows Installers. With this management interface, OpenVPN can be used by non-administrator users.This is also useful for Windows Vista/7/8/10 systems where elevated permissions are needed to add routes to the OS. NOTE: This is not currently compatible with the 64-bit OpenVPN installer. It will work with the 32-bit installer on a 64-bit system. What I've found strange No, no you don't get to comangle two questions in one with insufficient detail. You said previously everything works great . Cannot ping is not great, it's broken.  It may not be allowing icmp on Firewall / Rules / OpenVPN.

You can browse direct to the pfSense in tunnel ip address, it is listening. You will need a Firewall / Rules / OpenVPN allow access to self  (same as anti-lockout rule on wan) From the example you list it would be https://192.168.204.1 You should also be able to browse to the pfSense inside LAN address https://192.168.20.1 from example. The server side router knows how to get to all of those addresses, as seen in Diagnostic / Routes.

Yes, can be done with NAT, and does work. Setup regular openvpn connection, in your choice of flavour. Additional changes… client - change port to alternate chosen 53, 21 etc, ie not 1194 server - if 53, set DNS Resolver/Forwarder to not listen on WAN, by selecting only LAN, OPT, localhost etc server - firewall / NAT / Port forward   interface WAN, protocol UDP, destination WAN address, destination port 53 (or 21 etc), redirect target IP x.x.x.x (WAN actual address, or an alias of it,  but not localhost), target port 1194 vpn then connects., or at least in my lab it does. YMMV. Not sure how it would work with dynamic public IP on server side. Now you can vpn from places that block most outbound ports, but allow common ports like 53 , 80 etc, or to make it less obvious you are using vpn.

Firewall / Rules / OpenVPN Add a rule to allow the traffic you want. Below first rule, add another rule to drop everything (else).

You could use NAT 1:1 on the pfSense box. NAT the VPN clients onto some useful network range, ie hide whatever remote address they're using.

You're right, the gateway. I didn't notice.

It's in a seperate pluggable package. System / Package Manager / Available Packages OpenVPN client export

I have your scenario working reliably on a 867 Differences I can see from my config to yours ip virtual-reassembly ip virtual-reassembly in ip nat inside source static udp 10.20.0.2 1194 x.x.x.170 1194 extendable ip nat inside source static udp 10.20.0.2 1194 interface GigabitEthernet0/0/0 1194 (Assuming 10.20.0.2 is your pfSense box, which it could only be with 252 mask) Plus you need the access-list or access-group permit udp 1194 stuff

Cellular ISP does carrier grade NAT within their network.  Cell connections are generally not on connectable public IPs. You shouldn't need any NAT on your side to get a site to site connection working More like a) pfsense VM as OpenVPN server peer-to-peer on a regular fixed connection (fibre/cable/dsl)     Can be with public IP (bridge mode), or port 1194 udp forwarded from ISP side router b) pfSense router behind 4G connection, as Open VPN client, peer-to-peer. b) connects a), and maintains the connection, over 4G , 3G, whatever. You can access all of b)'s network from a), or even do a NAT port forward on pfsense a) to any b) address.

No worries, I'm glad it worked out!

Thank you very much for your help.

OpenVPN is routed, IPsec traffic selectors are in the kernel You can policy route into OpenVPN, not so with IPsec Along those lines you can forward traffic from the internet over OpenVPN to a target host and get the benefit of reply-to for the reply traffic. Not so with IPsec. IPsec generally performs faster than OpenVPN You generally don't have a lot of interoperability issues with OpenVPN. IPsec, particularly IKEv1, can be, umm, challenging. That's my short list of important differences

I figured out the problem guys, if anyone is interested. I guess my wireless carrier is utilizing some IPv6.  In the APN settings on my cell phone, it was set to IPv6/IPv4.  As soon as I set it to IPv4 only, my VPN started working as normal over the cell network.  It may be a bandaid solution but at least it is all working now.

I think I found the solution for my problem. I checked the two users which I used for testing and noticed that the CN in both user certs was the same. So I changed one of the CN and till then everythink works fine.

@panz: Yes, but my Foscam cameras are on a different and physically separated interface; the reason is: Foscam (and Dahua) "disable p2p" function on the GUI doesn't disable it at all, so I put them on a different network (different from my "trusted" LAN). I'm no It guy at all, but I kind of thought that one of the reasons we use pfSense is because it is versatile enough to work around shitty implementations like Foscam. By that I mean, why does it matter if the GUI for the webcams doesn't work? pfSense automatically blocks anything you don't write a rule to pass, and you can assign static IP's to your cameras and write rules specific to your webcams. So even if you specifically configured your cameras to make all of your feeds available to the world, if pfSense doesn't let that traffic out, it isn't going anywhere. You can even log all of the traffic on your webcams if you wanted to. Basically, is it really necessary to isolate the webcams on their own subnet? It seems like an extra, unnecessary step that is complicating things.

You need a static public IP or a DDNS service if your IP is dynamic to get a static host name. Set up the VPN server is self-explanatory when using the wizard. VPN > OpenVPN > Wizards

Hub and spoke from the perspective of one running OpenVPN server and a bunch of clients only works with SSL. Hub and spoke from the perspective of many external places connecting back to one datacenter can be configured with shared, but you'd need to set it a different OpenVPN server for every client. Which is why I didn't want to go down that path. The client override only applies to certificates that exist in the certificate manager, whether imported from somewhere else or created internally.

UPDATE: I notice odd things happening (like local pings being routed outside my network) with my network after routing each Interface down different gateways. I have since  improved my firewall rules so that ONLY protocols like DNS and HTTP are allowed to route directly out through its assigned gateway. I've included an example rule list picture. Note that I setup the same rules as in the image on the OPT1 interface. I also had to set a network bridge between the OPT1 and LAN interfaces. Now me and the kids can play minecraft on the local network again!!!  

It seems that there is something messed up in your ISP router. It translates the source address of incoming packets to its WAN address??  :o That's not a normal behavior. Some routers may translate all incoming traffic source to their LAN address, but WAN? Also very strange or a great accident is the exactly same source port of both connections. In the capture from the external connection attempt you can see the response packets from pfSense sent out to the WAN address. But obviously the router doesn't forward them.

Anyone perhaps able to tell, if this (LAN 2 LAN connect) is possible at all in this setup?