@boxofrox Ah! <Sound of penny dropping, lightbulb turning on, forehead slap> Thank you, I forgot about the “certificate granting” part of a CA. What do you call it when you’re too young for a “senior moment” and too old for a rookie mistake? ;-) Salaam, kudos, thanks!

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.