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.

@gjaltemba: You may want to set the Verbosity level to 5 under Advanced Configuration of the Openvpn client if you really want to check the log. Reset it when you are done. At Verbosity level 5 the line auth_user_pass_file = '/var/etc/openvpn/client1.up' is there. But now notice this error May 17 21:30:05 openvpn 79458 ERROR: FreeBSD route add command failed: external program exited with error status: 1

A couple of additional notes about my earlier posts.  First, I'm embarrassed about not being able to find the routing table in pfSense.  It's at: Diagnostics > Routes I thought it was Tables and my brain shut down even more when I didn't see what I expected. Second, I finally added the redirect-gateway command into the advanced options of my OpenVPN clients.  Everything seems to be working (hopefully, this "seems" is more accurate than my previous "seems").  My routing table now includes both 0.0.0.0/1 and 128.0.0.0/1 and both point to the x.x.x.1 address of my VPN Gateway Group's Tier 1 entry.  I assume it will switch to the address for the Tier 2 entry if the Group fails over.  Default is still there and still points to my WAN. And, finally, I guess the "Don't Pull Routes" box could be considered that GUI option to enable "redirect-gateway."  The trouble is that we don't know in advance what routes the provider will push if we leave that option un-checked.