Hi. For Firewall rules: https://www.youtube.com/watch?v=UZR2LNBtzrw https://www.youtube.com/watch?v=OfZPOO2nu5g For OpenVPN, these tutorials are nice. https://www.youtube.com/watch?v=xiy52Hn5bTc

Thanks Pippin, so it appears as though it's not disconnecting after an hour... I've narrowed it down to the keepalive values in the server config. They are set to 10 and 60. I found this in the server.conf file under /var/etc I'd like to modify this line (keepalive 10 60) value, or remove it all together, but I don't want to create instability. Is it safe to do this via the shell or is there somewhere in the GUI I can do this?

what version of pfsense are you running - I thought there was a bug report about firewall rules created for openvpn being incorrect.. But that was corrected.. https://redmine.pfsense.org/issues/8391 But it was using tcp4 vs tcp.. I just ran through the wizard and created a new udp server and it did not create any rule.. It created correct UDP with port and ipv4 [image: 1527778650278-udpopenvpnwizard-resized.png] Running 2.4.3p1

@jimp It was my phase 2 enteries that were messed up! Thanks for the help all is working now.

I have the same behavior on my setup. What I have noticed is that it's actually related to the frequency that you issue the icmp requests. Interestingly enough, the sweet spot seems to be 1000ms between icmp requests (I tried numerous times) you actually get more packet loss if you do 2000ms... for example: ping -i 0.2 google.com 103 packets transmitted, 24 received, 76% packet loss, time 21443ms ping -i 0.25 google.com 55 packets transmitted, 17 received, 69% packet loss, time 13744ms ping -i 0.5 google.com 49 packets transmitted, 23 received, 53% packet loss, time 24100ms ping -i 0.75 google.com 51 packets transmitted, 29 received, 43% packet loss, time 37550ms ping -i 1 google.com 20 packets transmitted, 20 received, 0% packet loss, time 19026ms ping -i 2 google.com 20 packets transmitted, 17 received, 15% packet loss, time 38014ms

That's possible though by adding routes, however, I'm wondering how your road-warriors can communicat with LAN devices when your LAN use another pfSense as default gateway. To you use TAP mode or NAT?

The images are gone for the time being at least but see the post regarding ssh here: https://forum.netgate.com/topic/74534/a-definitive-example-driven-openvpn-reference-thread/5 The key is you need an assigned interface on the side with the server that is receiving the connections and the rules that pass the traffic MUST NOT match the rules on the OpenVPN tab. They must match the rules on the assigned interface tab or you will not get reply-to so you won't have good two-way traffic.

@derelict Point well taken, about making a configuration backup. Thanks!

@periko said in SitetoSite and RoadWarrior Communication?: 10.0.7.0/24 viragoman is working, thanks for your great help!!!

Is all your DNS traffic (or at least DNS traffic for hosts from the VPN_HOST alias) routed through your VPN tunnels too?

I solved half of the problem. The problem was that the IP range of the VPN was not filled in my DNS. I can now solve the internal names. But unfortunately not the external names.

First off, using 10.0.0.0/8 as a tunnel network is not what you want to do. Change that to something like this on both sides: 10.186.216.0/30 192.168.0.0/16 covers both sides, so you can't use it as a remote network there. You want to set these remote networks: On site A: Remote Networks: 192.168.255.0/24 On site B: Remote Networks: 192.168.0.0/24 It is possible you are trying to supernet everything that is not a local interface but is in 192.168.0.0/16 from both sides, which should be doable, but I would simply get it working first. We are going to need to see full routing tables, firewall rules, etc to see why a supernet isn't working.

The OP asked about performing better. And that is the answer that was given. Needing to use TCP for other reasons is pretty much off-topic.

@mrpsycho said in OpenVPN Exiting due to fatal error: 10.8.0.2 What derelict failed to clarify is that you are attempting to assign the same IP address to two different interfaces. This occurs when you are trying to make duplicate VPN connections that assign the same IP address to a TUN interface that has already been used by another connection's TUN interface. Look at your OpenVPN logs and the address that are being assigned by your VPN provider via the PUSH= entries. If you see that each separate VPN connection is trying to use the same local IP address to assign the its local TUN interface for each connection, this will not work when using multiple VPN connections. Each connection needs to assign an unique IP address to it's local TUN interface or you will have a conflict as indicated by the "ifconfig: ioctl (SIOCAIFADDR): File exists" error.

@demihalf What you are asking for is what Gateway Groups do. Under System >> Routing, configure a gateway group that includes your two VPN connections. Configure your primary VPN as Tier1 & secondary VPN as Tier 2. And configure the gateway trigger for member down. Then configure your routing policy rules to use the gateway group as the outbound gateway. No need for a walk through, just read up on these pfSense routing configuration items, that's what they do.

@codemonkey76 By any chance are you running pfS 2.4.3? I ran into this same problem when upgrading from 2.4.2. No change in Configuration(s). Same firewall rules. Can connect and ping port addresses of pfSense box, but not beyond. Worked perfectly with 2.4.2 (and 32 bit versions). Same openvpn version (2.4.4), same SSL library version(1.0.2m) on both 2.4.2 and 2.4.3 I'd like to understand what has broken.

@jausk said in Extremely slow OpenVPN: Update: switching to TCP seems to improve performance significantly. Over TCP I'm getting 30/30mbps UDP does not acknowledge sent packets, TCP does. Generally, due the extra overhead of acknowledging packet exchange via TCP, tends to cause more overhead, thus less achieved bandwidth vs. UDP, which is why UDP is the default for VPN services. And protocols that use UDP are considered to tolerate intermittent packet loss. So if you're experiencing an increasing in throughput with an acknowledged exchange protocol vs. a lossy protocol, that suggests something in the connection link may be priority throttling /losing/dropping packets, affecting overall throughput based on lossy vs. lossless protocol exchanges. This also does not rule out a packet size negotiation issue that may be the difference between your UDP and TCP connection differences. If TCP is giving you improved bandwidth over UDP, use that the explore if there is a packet fragmentation or priority issue in the upstream link between you, your VPN provider, and your target throughput test service.