@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.

@sparkman123 said in Cloudflare DNS + PIA: @TechyTech: Then create two outbound float rules on your WAN interface, the first to allow only DNS-SSL to CloudFlare, and the second to block/reject any non SSL DNS out the WAN.  This will restrict only DNS-SSL out the wan while the WAN is being used for DNS until the VPN links come up and DNS traffic is routed out the VPN. For the second rule you mentioned, I assume you would create this rule by blocking any traffic whose destination port is 53 and destination IP is not 1.1.1.1? Basic answer Yes. I actually have a few rules I use depending on what I'm playing with. Since I also have been testing Tenta's DNS-SSL, I create an alias of DNS forward hosts, then one rule to allow only DNS-SSL (port 853) to allowed forwarders (defined by host alias), then another rule to block any other DNS (53/853) in case any other client tries to use their own DNS, so that only my defined forwarders are allowed only DNS-SSL out the WAN and any other DNS activity (SSL 853 & non-ssl 53) is blocked. Mix and match as you need but the jist of it is to allow only DNS-SSL, restricted to the DNS provider of your choice if you desire, then block any other DNS activity egressing via the WAN that didn't pass the first rule, until the VPN link is up and routes to DNS are shifted over. Ultimately I only have rules on my WAN that allow only DNS-SSL to specified forwarders and OpenVPN to specified VPN hosts, and everything else egressing the WAN is blocked. This allows DNS to get the VPN service host address, and connection of the VPN links, and blocks anything else that may default out the WAN until the VPN links are brought up the the routing is shifted over to the VPN links. Also, have you tried your configuration with any dns leak testing sites? i.e. dnsleaktest.com or whoer.net? My problem is, regardless of my settings, I get US based Cloudflare is detected as my DNS server. 1.1.1.1 like googles 8.8.8.8 is an ANYcast address. Basically when you access it it's like saying give me the closest UNIcast address associated to this ANYcast address. How your ISP handles AS group routing may affect the use of ANYcast addresses and the resulting UNIcast accessed host. As example: When I run the DNS leak test, it detects the actual IP's of the Cloudflare DNS servers that got accessed, not the 1.1.1.1 / 1.0.0.1 address that is configured as the forwarder. For example, when I use my normal LAN connection with my regular default gateway, I get Cloudflare US as my DNS (as expected). When change the default gateway of my LAN to my VPN connection (which is a tunnel to the UK or New Zealand) I'm still getting Cloudflare's US based DNS servers even though I should be getting Cloudflare's servers in those countries. Based on this behavior, from what I can tell, It's almost like the DNS traffic has its own independent tunnel outside of the VPN/default gateway. This depends on where the traffic is coming from and what you have configured for outbound interfaces under DNS resolver. If coming from your LAN it will go via policy or default route as LAN rules define, but if initiated from the firewall, coming from the DNS resolver, unbound will try to access all configured DNS directly out each configured outbound interface, even bypassing routing. To wit, it will keep track of which DNS was accessed and how quickly, via each interface and attempt to optimize future activity from there. When using a VPN client and shifting your default route this can cause some unexpected behavior between expected routing due to direct out the interface access. So, in short, where your LAN client is getting routed to, and where pfSense sourced services are routing to do not always go the same routes. Simplest way around this is to only use on the lo or 127.0.0.1 interface as the outbound interface for DNS resolver under pfSense, this will cause all traffic from the firewall dns to go through routing, as well as limit unbound from attempting to access each defined forwarder more than once (all forwarders per each outbound interface), such that when your VPN client is up and becomes the default route, your DNS traffic will shift to the temporary default route (def1) accordingly. Similarly is to define a gateway for each DNS under System >> General, this will cause a static route to be created for that DNS when the defined gateway is up, otherwise it goes through default routing, but he same direct out interface issues noted above still come into play if you have additional interfaces defined.

It seems like I have finally solved this while debugging some other issues I've had with an OpenVPN client connection. The final solution for this problem seems to have been that pfSense cannot set up routes correctly to openvpn client connections, and instead falls back to setting the interface as "lo0" when checking netstat -rn. I debugged this while creating a dummy route towards 1.2.3.4/32 under "Static routes" and attempted setting my OpenVPN clients gateway as the route, and then checked "netstat -rn" for the results. After editing my OpenVPN client setting " IPv4 Remote network(s)" and adding 0.0.0.0/0 to it, I am able to set this connection as gateway for certain addresses and, for example, DNS-servers under General Settings and seeing pfSense finally setting the gateway to "ovpnc2" as the interface instead of "lo0".

i've done this for years.. i assigned my devices static ip addresses that i wanted the traffic going through a different gateway. once that is done and your VPN connection is working go to: firewall > rules > Lan > add that computer and identify it so you know what it is, edit the rule then under gateway change it to your WAN interface. apply everything else will go across the VPN like normal. only that device will transfer over the WAN interface

I presume, the routes on the client are not added by pushing from server. Check the clients routing table.