@viragomann said in triple site to site working, but 2 pfsenses can only ping the oVPN server site.: Normally you don't need a route for the tunnel network, because you can as well access the remote firewall by using its LAN address. No, I couldn't.... The 2 pfsense configured as client were unable to ping anything on the other pfsense. They can now.

Your OpenVPN should be listing on a WAN type interface. So it is ... but after a few hours I discovered that pfsense had lost this setting. Set it to "Any", set it back to "WAN" and the problem was solved. Why would you want do that ? Virtual Private Networks — OpenVPN — Assigning OpenVPN Interfaces | pfSense Documentation

@travelmore said in OpenVPN not connecting: to other, whereas in that link the person mentioned changing it to Interface IP address instead of other. Be careful with this : [image: 1677478553862-cba53f1e-fee1-42d5-8f76-215842ebfc49-image.png] as that a hostname like (RFC1918 like 192.168.0.b) this will be wrong in 99,x % of all cases. When you are out, somewhere in the wild, surround by the hostile Internet, and you want to connect to 'home' over VPN, you have to connect to your ISP WAN IPv4. Certainly not to your RFC1918 like 192.168.0.x as shown in the image above, which can't be routed over the net. So : second best choice : the ISP WAN as a host name. Host name is your tunnel end point, and as the comment says : it could be an IP or a host name. If you shose the latter, it should be resolvable there where you are now. Said differently : it should be resolvable anywhere on the internet. So : best : set up a DYNDNS so that a known 'hostname' always points to your ISP WAN. This is valid and useful if you have a dynamic IP and/or a static WAN IP.

@huydra I should had TL;DRed the thread... Got bumped up.

@viragomann That's exactly what I needed.... I made the change and tested...my public ip address matches my home address Thank you soo much!!!

@ikonomn most ISP routers will have a way to forward ports to an internal device (your pfSense) or set one as DMZ to forward all ports.

@mcury Oh, interesting (and sad). I was able to enable CBC ciphers in the OpenVPN server and choose hw crypto for that as well. Can't tell if it works though. We will test and monitor CPU load etc for a check.

@nicp91-0 (I'm no pro, but...) I'm curious - did you ever try setting the gateway's monitor IP to the IP of the server you're connecting to? Also, could be that since 9.9.9.9 is a DNS server, and some of these privacy VPNs might try to get you to use their DNSes (for privacy... maybe they block access to public DNSes like 9.9.9.9). Fo my setup, I pinged the server name that's in the .OVPN file from the privacy VPN server and used that IP address in the gateway's monitor IP.

@gandalf33 said in OpenVPN TLS routing issue, shared key working fine: iroute 192.168.0.0 255.255.255.0; iroute does not work with DCO according to the docs. So instead of this line try route 192.168.0.0 255.255.255.0 10.8.11.2;

Ok. I've managed to fix it. I used OpenVPN import functionality and it has imported the tunnel and it works as expected. Quite strange for me, but I compared the backups and it seems that the OpenVPN interface refuse to start when you put remote networks. Left the field empty allow the OpenVPN client to pull this settings from the server and it correctly set the needed IP address of the tunnel. All good. End of story. I still can't answer to myself why the OpenVPN daemon returned exit status 1 and quit without any warnings/errors when I tested it in the console.

This is a KI: https://redmine.pfsense.org/issues/13963 The "kldxref /boot/kernel" and a reboot resolved it.

@deviace If I understand your request correctly, watch this video a few times. It's kind of tailored to "Privacy VPNs", but I think it might apply to your OpenVPN interface. https://www.youtube.com/watch?v=ulRgecz0UsQ It discusses setting up a "tagging" rule on all of your LAN interfaces/networks and then use a floating rule to act as a "kill switch" to prevent the tagged packets from going out the WAN. In this approach, the default gateway is still set to WAN, but you set all your LAN/OPT/VLAN interfaces to use the OpenVPN interface. Hope I'm not sending you on a wild goosechase.

i think i got it. i disabled DCO and that seems to have fixed it. i can now hit the remote local resources and dns entries over there work now as well..:)

@viragomann got that figured out. thanks. I am now having as different issue that i will start another thread for..thanks again.

The same behavior was on the second unit connected via VPN. 23.01 with enabled DCO on VPN tunnel breaks Traffic Graph. Is any fix/bug available?

Dear all, I've discovered with plenty of pleasure that is possible to split DNS traffic. You just need to associate a zone to DNS :) https://openvpn.net/vpn-server-resources/troubleshooting-dns-resolution-problems/ (-> "Split-DNS when using DNS Resolution Zones") if you configure on your firewall (Pfsense or what else) that for a specific "intranet" zone you have to query a specific DNS, that's work! I've verified directly on the firewall (.91 is my IP address from the OpenVpn assigned subnet) tcpdump -i ovpns1 src 10.x.y.91 and port 53 DNS queries for xyz.lan appear in the dump otherwise not (ISP DNS are used) [image: 1677062169195-683d84ef-76ed-4027-8246-33f818df2e0c-image.png] Although you'll have to use OpenVpn client... (with tunnelblick, e.g., it will not split DNS) That's all I needed. Thanks to all