@flat4 You're right, it just happened to me, on pfsense tabs. Open VPN logs 2023-08-08 17:27:23 Initialization Sequence Completed 2023-08-08 17:29:19 [Server_CA] Inactivity timeout (--ping-restart), restarting 2023-08-08 17:29:19 SIGUSR1[soft,ping-restart] received, process restarting 2023-08-08 17:29:24 TCP/UDP: Preserving recently used remote address: [AF_INET] 2023-08-08 17:29:24 UDPv4 link local: (not bound) I lost the connection. Server problem.

@viragomann alright, I looked up for MTU/MSS keywords under OpenVPN for system logs in pfSense, and keep seeing this pop up. [image: 1691521933819-26ddef79-e9ae-4386-888d-bf5ab2d9a251-image.png] Does that tell us anything that we need to know? From my understanding, my PC has a 1500 default MTU, and we probably want to keep it that way. If not, I'm open to making changes. As for pfSense, which MTU/MSS would I want to change? Is it the OpenVPN gateway or my WAN? It's blank in there for it all, and I'm assuming that's also set at 1500? The screenshot above mentions the payload being 1600 and 1768. Does that mean I have to increase my MTU or something? I'm sorry; first time dealing with this stuff, and I really appreciate your input.

@BlazeStar pfSense 23.05.1 uses OpenVPN 2.6.2., so here it is https://openvpn.net/community-resources/ You'll see that "Allow Compression" is something of the past. See also here https://openvpn.net/community-downloads/, goto the 2.6.2 release info. Look especially for the info "what was done using 2.4 and 2.5, and goes away with 2.6". My next best proposal, must see info are thee : Youtube => Netgate => Videos. There are at least 3 OpenVPN server videos. You 'must' see the first 2 of them. Even if they are old, they are still very valid. These videos are quiet long, but will give you the main oversight of all the aspects. Look at the the 7 minutes Configuring OpenVPN Remote Access in pfSense Software which will answer already most of your question. Last but not least : HEADS UP: OpenVPN deprecating shared key mode, requires TLS, deprecating cipher selection. Btw : OpenVPN is one of the VPN methods. There are others.

I think I found the culprit, yet I have no idea how to fix it: Aug 5 19:49:25 pfSense filterlog[41547]: 5,,,1000000104,ovpnc1,match,block,out,4,0x0,,63,0,0,DF,6,tcp,141,10.15.0.2,OUTGOING_IP,13281,443,89,FPA,1717258034:1717258123,761365153,2048,,nop;nop;TS I see that it also blocks the OPT1 traffic in the system log, as it mentions Default deny rule IPv4 (1000000104). Does anyone see anything wrong with the instructions I posted in the first post? It doesn't mention any firewall rules on the OPT1 or OpenVPN tab. However, I have come to believe this is no longer correct. Yet when I allow any traffic, it also still doesn't work. It could potentially be asymmetric routing according to the documentation, but I use UDP as a protocol, which it mentions that it shouldn't affect it (https://docs.netgate.com/pfsense/en/latest/troubleshooting/asymmetric-routing.html). Any help would be greatly appreciated!

Hi. I had a similar problem. It started after I upgraded to 2.7.0. Several OpenVPN Peer to Peer connections with Shared Keys stopped working. SSL/TLS were still operational. After collecting all informations i found out: the tunnel connections are functional, but i could not communicate from the Servers side (where the OpenVPN Server is) LAN. the clients are on pfSense 2.3.4 most (because of older hardware) i could reach the clients LAN from the pfSense Server shell because of multi WAN the tunnels are bind to LAN The solution was: add firewall rules on LAN with source LAN NET and Destination the Client side LAN network and choose the Default Gateway under advanced.

It's almost certainly a problem with your configuration. Check one of the other many threads in this category where people also claimed to have issues, they have all turned out to be broken configurations that worked in the past by sheer luck/coincidence. As OpenVPN matures they deprecate certain behaviors or make things more strict which can be confusing at times. There are also sometimes changes in the base OS that come into play. But in each case so far it's been something wrong in the configuration. The other threads are full of suggestions of things to look for and adjust.

@stl_saint ok then yeah, if you were on some cgnat IP for pfsense wan 100.64-127.x.x then no you wouldn't gotten anything inbound to pfsense - unless is was specifically setup on the isp for you.

@deivison90 ?

@kasteensma said in Private Internet Access ( PIA ) VPN installation on Netgate 1100: Has anyone accomplished this job? Can you advise? the differences between the screens on 2.6 and 23.05.x are very small. I would just give it a shot.

Thanks Jim, Problem solved. Ricky

@mauzilla said in Accessing a VIP IP on the WAN side when connecting to openVPN: In my local openVPN confige I have route-nopull Basically access to the WAN VIPs should work normally with this option. But why don't you just uncheck "Redirect gateway" in the server settings and enter the local subnets to be routed over the VPN instead? You can also go the other way round and route the whole upstream traffic over the VPN (including the VIPs) and enable NAT reflection for 1:1 NAT.

@Bronko you don't want to use NAT? unfortunately, NO

@Gertjan Ok so I was able to connect to the VPN from my laptop using the bluetooth connection for the hot spot since I disabled wifi on the cell phone to ensure all traffic going over cell provider. Cell service is weak here so it is slow but traffic is passing (see below). So I guess given this can now confirm vpn is working across the 2 devices as expected but why the initial issue or can it be considered a one off and is everything else setup as it should for best performance and security. [image: 1690469137531-0c5ca90b-4860-4044-aa3e-5912349a7f20-image.png] [image: 1690469098950-2444eff2-8883-4053-ac52-a59f63729199-image.png]

Start your own thread, it's unlikely to be the same issues others have hit. While symptoms may be similar, there are numerous possible causes that can look the same, and trying to diagnose multiple people's issues in a single thread is not feasible.

Just to close this off, I got it working as desired using a simple Peer-Peer OpenVPN, and then added a bridge from VPN to OPT1 at both ends. Client CPE & Juniper VRF can reach each other with perfectly. The only remaining challenge was the size of IPSEC packets from the client. Control packets were small, but Data often exceeded the payload maximum inside the OpenVPN tunnel. Eventually I used tun-mtu & fragment options to split packets >>1400 bytes across two OpenVPN UDP packets. LAN interfaces are completely separate and only used for local access to the PfSense GUI. [image: 1690446392161-pfsense-openvpn.jpg]