It looks like I've solved it, and, as Derelict said, it was a policy routing issue.  My firewall rule for allowing traffic from that interface out to the WAN was missing a Gateway.  It was: Pass IPv4 *  GUEST_LAN net  *  *  *  *  none      GUEST_LAN: Pass WAN (Pass Any, But Local Already Handled) and I changed it to: Pass IPv4 *  GUEST_LAN net  *  *  *  WAN_DHCP  none      GUEST_LAN: Pass WAN (Pass Any, But Local Already Handled) I assume the issue was that I hadn't specified how the traffic was supposed to leave, so it defaulted to whatever the system was set up to use.  Before the "redirect-gateway," that was the the WAN.  Afterward, it was the VPN.  Once I added the gateway, that got specific enough to override the use of the VPN and actually use the WAN.

Thanks for your reply, Yes I set up site to site connection and connection state is also up. when I'm exporting the same configuration and using in a windows PC everything works in expected way, and in client pfsense router also in states looks everything fine and even receives the intended IP address from site one DHCP, my question is now my router has three ports: one is connected WAN one is connected LAN and one is free, when I connect my pc to LAN port it received IP from my current network (network of site2) not receiving IP from site1 DHCP, I really have no Idea I tried to bridge between LAN and openvpn port and other tricks but nothing worked and hope someone help me what to do that every pc in sited 2 connected to pfsense client router receive ip from site 2 DHCP.

I've been running a Syslog server so I can record the activity logs for my pfSense box, but there are aren't any notable errors or warnings. I used to only capture OpenVPN logs, but changed it to all when I wasn't getting any useful data. I was getting a lot of Authenticate/Decrypt packet error: bad packet ID errors so I changed my OpenVPN client from UDP to TCP. 2017-05-21 14:14:23 Daemon.Error 192.168.1.1 May 21 14:14:22 openvpn[43547]: Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #2241995 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings The network still loses connectivity on TCP, and the only other unusual thing that the log shows is that the unbound service has a tendency to restart a lot. 2017-05-21 16:41:09 Daemon.Notice 192.168.1.1 May 21 16:41:07 unbound: [35012:0] notice: Restart of unbound 1.6.1. 2017-05-21 16:41:09 Daemon.Notice 192.168.1.1 May 21 16:41:07 unbound: [35012:0] notice: init module 0: iterator 2017-05-21 16:41:09 Daemon.Info 192.168.1.1 May 21 16:41:07 unbound: [35012:0] info: start of service (unbound 1.6.1). 2017-05-21 16:41:09 Daemon.Info 192.168.1.1 May 21 16:41:07 unbound: [35012:0] info: service stopped (unbound 1.6.1). 2017-05-21 16:41:09 Daemon.Info 192.168.1.1 May 21 16:41:07 unbound: [35012:0] info: server stats for thread 0: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting 2017-05-21 16:41:09 Daemon.Info 192.168.1.1 May 21 16:41:07 unbound: [35012:0] info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0 2017-05-21 16:41:09 Daemon.Info 192.168.1.1 May 21 16:41:07 unbound: [35012:0] info: server stats for thread 1: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting 2017-05-21 16:41:09 Daemon.Info 192.168.1.1 May 21 16:41:07 unbound: [35012:0] info: server stats for thread 1: requestlist max 0 avg 0 exceeded 0 jostled 0 2017-05-21 16:41:09 Daemon.Info 192.168.1.1 May 21 16:41:07 unbound: [35012:0] info: server stats for thread 2: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting 2017-05-21 16:41:09 Daemon.Info 192.168.1.1 May 21 16:41:07 unbound: [35012:0] info: server stats for thread 2: requestlist max 0 avg 0 exceeded 0 jostled 0 2017-05-21 16:41:09 Daemon.Info 192.168.1.1 May 21 16:41:07 unbound: [35012:0] info: server stats for thread 3: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting 2017-05-21 16:41:09 Daemon.Info 192.168.1.1 May 21 16:41:07 unbound: [35012:0] info: server stats for thread 3: requestlist max 0 avg 0 exceeded 0 jostled 0 2017-05-21 16:41:09 Daemon.Notice 192.168.1.1 May 21 16:41:07 unbound: [35012:0] notice: Restart of unbound 1.6.1. 2017-05-21 16:41:09 Daemon.Notice 192.168.1.1 May 21 16:41:07 unbound: [35012:0] notice: init module 0: iterator 2017-05-21 16:41:09 Daemon.Info 192.168.1.1 May 21 16:41:07 unbound: [35012:0] info: start of service (unbound 1.6.1). Other than that the only thing the logs show are numerous filterlog entries.

Just thought I'd chime in and say I resolved a similar issue by disabling 1:2200073  SURICATA IPv4 invalid checksum It was blocking PIA.

What do your IP addresses look like?  Do you have firewall rules to allow the traffic coming from your VPN clients' interface access to your local devices?

I found a way to test udp using Packet Sender (https://packetsender.com/) on the local computer and a remote computer (outside my network). One computer sends a udp packet and the other receives it and reply. I found 2 things: Remote computer -> pfSense -> Local computer (192.168.20.125): It works ! The port forwarding actually works ! I even get a reply (no clue how that's possible) since… Local computer (192.168.20.125) -> pfSense -> Remote computer: Fails, pfSense never seeds the packet to the VPN. So, it's not a port forwarding issue. I'm guessing it's a NAT issue or a routing issue (is there a difference ?). Not quite sure what to do about that... Not even sure this is related to OpenVPN... Should I start an other threat ?

Unfortunately it's not client firewalls either, I checked that. I can only think it's broken for me (or me that's broken!). I'm going to see if IPSEC works any better, or helps me diagnose the problem, but that's not looking good at the moment either. That's saying auth failed, when the pre-shared secret is definitely identical. I'm missing something obvious and daft clearly! Trawl the internet and docs read and re-read I guess. No Idea what is going on with openvpn and site-to-site, but I got IPSec working fairly quickly. So I'm happier with IPSec for site-to-site anyway - I can only think there is something broken with openvpn site to site with my setup somehow.

It is in the client exporter. Use the dynamic DNS name which should be available under Host Name Resolution if you are using pfSense to maintain the DynDNS record. If you are maintaining it some other way, use Other and enter the dyndns name there. You will probably also need to create a new OpenVPN server certificate with a CN AND a SAN of the dynamic DNS name, not an IP address.

Solved my DNS query refused by adding the correct ACL to the DNS Resolver for OpenVPN.  Funny how the UDP VPN connection worked without any ACL.

Oke so I have to put rules into the openvpn interface to stop guest users from connecting to the other local interfaces. I could then use a different openvpn server for myself. But then I need to use a different authentication too because else guest users can still access all openvpn servers. So I could use local user database for myself and freeradius for the guests openvpn server. Not exactly what I was hoping I could do but this way it may work. Thanks for clarifing the end point of openvpn tunnel.

Thank You @jimp!! I really appreciate all your help and prompt replies.

Hi Everyone! Im from Brazil and i have a some problem. My CA restart in 30 minutes. sent error in my client : "Thu May 18 17:43:19 2017 [server-certificado] Inactivity timeout (–ping-restart), restarting Thu May 18 17:43:19 2017 SIGUSR1[soft,ping-restart] received, process restarting Thu May 18 17:43:19 2017 Restart pause, 2 second(s) Thu May 18 17:43:21 2017 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info. Thu May 18 17:43:21 2017 Socket Buffers: R=[163840->131072] S=[163840->131072] "

Yes they can work that way so long as the Server Local Port is 443 and only the client's Server Port are 443 then it's talking about different things (source port vs destination port). The only way they would conflict is if you also set the Client's Local Port to 443 but you'd never want to do that.

@beremonavabi: By the "interface setting," you mean under VPN > OpenVPN > Clients? (see attached).  If so, mine's set to WAN, so I should be fine. Yeah that's what it means, and yours is A-OK if that's how it's set. @beremonavabi: Thanks for the reply.  I appreciate it (and assuming those are your videos on the Hangouts site, I find them very useful for trying to get a handle on this stuff). That's me… Thanks!

Related question for options to get OpenVPN to reconnect after service interruption: The issue that I just ran into is the OpenVPN client did not reconnect after a service outage, and it is at a remote location. The remote location is a residential location connected via cable modem/DHCP, and the current options are to cycle power to pfSense, or use a remote desktop support to control a PC at that location to access pfSense to restart the OpenVPN client.  Both of those options are viable, but I would prefer a self-healing option. For recovering from an OpenVPN service interruption, does it make ANY sense to have TWO openVPN connections between two pfSense firewalls, so that if one route does not restart itself after a service interruption, the other route will? (e.g, Site A client –> Site B server, AND Site A server <-- Site B client), or does this type of configuration just create more problems? The alternative I am planning is to use a PC configured as an OpenVPN client to both pfSense servers (it is already connected as an OpenVPN client to one for remote access), but I would need to set up dynamic DNS at the remote site because it gets its IP via DHCP from the cable modem provider.