Updated and simplified explanation:

@viragomann Thanks for your reply. Any RFC 1918 could be used for TN*. Let´s say it is 192.168.100.0/24. And it is distict from any other used net. O.k. You recommended a smaller net, but the functioning VPNs are /24 too. There should be no problem with the tunnel itsself, as with additional routing information on a clients sides computer, packets are passed through, and to answer another question: From a computer on site of the PFsense to the remote site and back.

Analyzing the routing table shows 192.168.100.1 (OpenVPN server side) as a gateway for the remote network. In the routing table 2 entries with gateway "link#12" for 192.168.100.1 and 192.168.100.2 (OpenVPN client side) can be found too. I guess "link#12" means that 192.168.100.1 and 192.168.100.2 are some kind of bridged. This is analog to what I can see on a remote PFsense acting as a client.
Ping to the remote site is possible, if a route on the pinging maschine is added to the remote net with 192.168.100.2 as a gateway. (In the routing table of the PFsense 192.168.100.1 is used as the gateway)

Some site on the internet suggests to take out the remote net from VPN client configuration and add a route with 192.168.100.2 via SSH, config.rc etc. I don´t like such solutions, because you can´t find them in config-firewall....xml
I think the "system-routing" menue won´t help in this situation.

What has gone wrong. Why points the routing table to the transfer ip on the other side (192.168.100.1) and not to his own ip of the transfer net (192.168.100.2)?
Why does this work between pfsense only and not generally with OpenVPN?
Is there/will there be a fix for this problem?

Another try to desribe: A packet for a remote site computer is sent to the PFsense. The PFsense has a routing table rule to send it to 192.168.100.1. This IP is assigned to the remote site and the packet is not routed. I didn´t make this entry -it is automatically created- But it would need to be 192.168.100.2 which is an ip of PFsenses side of the tunnel.

I´m I allowed to post a link outside netgate.com? Would make the problem much clearer.

@mrsliff said in OVPN Server with DD-WRT client - remote network not reachable:

10.1.200.0/24 (OpenVPN network for p2p connection)

Since it's a P2P, you should use a /30 mask for the tunnel network.

@mrsliff said in OVPN Server with DD-WRT client - remote network not reachable:

also set up Firewall rules to accept any to any on OVPN Network

Rules on the OpenVPN tab has no impact on the outgoing traffic to the client side, only these ones on the LAN.

Silly me, I was missing the client specific override that tells the server to route the network behind the client.

All good now! 😃

@profit

As long as this

ed41177d-9e73-42f7-b072-cd834e561321-image.png

isn't running, its normal the OpenVPN client won't be able to connect.

So, first things first :
Start the OpenVPN Server "New_VPN" and look at the log :

05ba0ecd-f85f-4f39-bc4b-2d25d67a3324-image.png

if it stops executing, it should log the reason.

@profit said in Service not running or connecting...:

No matter if I create a new server...

Somewhat normal, if you use the same 'wrong' settings.
What settings ?

These settings : https://www.youtube.com/watch?v=jQHqPq7ftz4 are known to work.

@jimp thats the nuance I was missing, thank you.

The servers cipher order is

CHACHA20-POLY1305 AES-256-GCM AES-256-CBC AES-192-GCM AES-192-CBC AES-128-GCM AES-128-CBC

Configuring pfSense with only AES-128-GCM added to the allowed data encryption list, and having AES-256-CBC as the fallback data encryption list results in a client side of data-ciphers AES-128-GCM:AES-256-CBC.
Given these two configurations its correct that the servers higher preference for AES-256-CBC is selected over the GCM cipher.

My mistake was thinking the client had more control, and the fall back option was a last hope fallback, not evaluated equally and as part of the allowed cipher list.

thanks for clearing this up

@zombat

Deleted the OpenVPN server and recreate it without using the wizard. Seems to work now.

@viragomann

Hi, I will try, thanks

@stevemosher said in OpenVPN Limits?:

Hi there,

We are trying to load up a couple nord tunnels here. We can successfully get 2 running but when we try a third we keep getting "Unable to contact daemon Service not running?"

I tried this also with another VPN service and again pFsense will only allow us to create 2 per vpn service provider.

Man how stupid can stupid be. I didnt even enter a password :)

We can close this

@m0t0b0y1337 said in PfSense-OpenVPN only conection:

I do not have a license to use its vpn. there we will use pfsense. understood?

Well then just replace it with pfsense - problems solved.

@viktor_g thank you very much. That explains it.

@johnpoz Update : The Issue is fixed now by re exporting the client profile and dns is also seems to be working.

Users have a hard time understanding leak test to be honest.

For example if you point to google you might get all kinds of different IPs, not the 8.8.8.8 you are pointing to.

If you point to some vpn DNS, a dns leak would show you the resolver IPs that its pointing too.. And not the specific IP your pointing too..

All a dns leak test does is have your client look up some unique fqdn.. And then what IP actually came and asked for that specific fqdn.

@griffo said in Route Traffic via VPN:

https://docs.netgate.com/pfsense/en/latest/recipes/wireguard-client.html

The second choices is what I want. To route all outbound traffic to my VPN provider.

@johnpoz

True. I never said that it has something to do with pfsense. But I found the problem and perhaps it might be interesting for others.

I dig a bit further and I did figure out that it has to do with the MTU Size of the packets in connection with certain providers.

How did I come up with it?
Yesterday I did configure one Notebook here in the office with openVPN and rdp connection. I did use our Guest lan to test it.

openVPN => works
RDP => works

Today the Notebook is at home and I have the described problem.

So I did start playing arround with ping MTU size (option -l) and did figure out that I can get a reply with packet size 1471 but not anymore with 1472.

I did use the custom option in openVPN server config and did try it with tun-mtu 1300; and it works!

I will now try to figure out what the best MTU size is.

thanks a lot for your help, always usefull to me!

@viragomann I agree, and we run pfSense with that turned on our on-premises hardware. However, when installing the official AMI in EC2 (and paying for it), I'd expect the defaults to be compatible with AWS' virtualized hardware edge-cases.

@gertjan Thanks for the link to the channel. I will definitely see everything.

You have two interfaces.
OPENVPN
OpenVPN

do they both need them to work correctly?

So after deleting the Virtual IP, clearing the "IPv4 Remote Network(s)" fields on both of the OpenVPN configs and adding in Static Routes for the remote subnets, it seems this is now working and the Static Route persists between tunnel reconnects. For some reason it still doesn't seem to work without defining a Static Route for the remote subnets to route over the VPN Interface gateway, but nonetheless, it works!

Would have never even considered to look in the Virtual IPs, thanks for your help @viragomann 👍