@thomalv
Add a rule to the WAN2 interface tab to allow access to the OpenVPN server, state a unique description and ensure, that it is applied to the incoming traffic to the server.

Remove floating pass rules or pass rules on interface group tabs, which may match the OpenVPN traffic, if any.
For connections passed by these rules, the reply-to isn't set. But it's required to send reply packets back to the correct gateway.

Note that floating quick rules and interface group rules have precedence over member interface rules. So you have to ensure, that none of these match the VPN traffic.

@Gertjan Unfortunately, that was pretty much the entirety of the openVPN log.

I did figure out the problem. It had already been a long day getting this network updated, and in my haste to configure the openVPN server I overlooked the IPv4 Tunnel Network entry. After a good night's rest and looking at my configuration anew, I noticed my mistake, I entered the required tunnel network, and the service started without any more errors.

Thank you for your reply.

@delphi5
Why didn't you open a new topic for your issue?

Regarding your issue, why don't you run the peer to peer server on pfSense? You can run multiple OpenVPN servers for different purposes and as well clients concurrently.

Gateway distribution: Some of our clients use 10.10.10.1 (pfSense) as their gateway, while others use 10.10.10.2 (VPN server).
The second VPN server (10.10.10.2) is configured as a tunnel between two locations: one in our company and the other in Canada.

Why are the local clients configured to use the second server as default gateway at all?
Just add static routes to them for the remote network.

However, more reliable if you want to run this connection on a different server, would be to put it in a different network segment than LAN and route the traffic on pfSense. So all local devices could use pfSense as default gateway.

I use the SafeXcel and disable the IPsec-MB Crypto, it is much faster with OpenVPN connections that way for my 2100. I use to have both enabled but it caused a slower connection for some reason. The way I look at it, if you have a dedicated crypto chip use it and deactivate the other.

@stevencavanagh
As far as I know, it does. If you choose to direct all upstream traffic over the VPN "redirect gateway" should be set in the server, which might be the case, since you cannot access the internet.

Then need an outbound NAT rule to masquerade the internet traffic from the VPN client. You mentioned above, that there are outbound NAT rule. Ensure that the source is the OpenVPN tunnel network in the additional rules, apart from the rules for LAN subnet.

And also you should provide a DNS server to the clients. This can be a local or a public one, but ensure that access is allowed.
If you provide the local DNS resolver, maybe you need to add the tunnel network to its ACLs. Access should be allowed automatically, but this doesn't ever work.

@techtester-m

Sorry you had to wait five years for the answer, but here it is.

Yes, you can do this. But, how you accomplish it depends upon how your devices are configured to get their DNS.

If you set-up PfSense to route all traffic from a particular device on a particular IP over the VPN, and that device attempts to get its DNS from a public DNS resolver, then the DNS requests, like all traffic from that particular device, will already go out over the VPN.

So, for example, if you configure Pfsense to send all traffic from 192.168.1.15 to a VPN, and 192.168.1.15 is configured to get DNS from 8.8.8.8, then when 192.168.1.15 attempts to query 8.8.8.8 for DNS, that traffic (like all traffic from 192.168.1.15) will go out on the VPN.

But, if you configured 192.168.1.15 via DHCP and you told it to get DNS from YOUR ROUTER (192.168.1.1), and your router responds to DNS queries, then that traffic will NOT go out on the VPN. It will go to your Pfsense router, which will then obtain its DNS information however it normally gets it. If you configure your router to get secure DNS, the request will be encrypted, but it won't go out the VPN. If you get it from unencrypted DNS servers on port 53, the traffic won't be encrypted.

There is a way to accomplish this, however, and that is by using a Port Forwarding rule. You would set-up a rule that automatically forwards any requests to port 53 from 192.168.1.15 to use a specific DNS server on the internet (such as 8.8.8.8). That would prevent 192.168.1.15 from using the router for DNS, but would instead send the query out on the internet. Here's how:

Firewall -> NAT -> Port Forward
Interface: LAN
Protocol: TCP/UDP
Source: Address or Alias: 192.168.1.15
Destination Port Range: DNS / DNS
Redirect Target IP: 8.8.8.8
Redirect Target Port: DNS
Filter Rule Association: Add associated filter rule
Description: Force DNS to VPN
Firewall -> Rules -> LAN

Edit the rule "NAT Force DNS to VPN"
Show Advanced
Gateway: (Select your VPN Gateway Here)

The "add associated filter rule" and editing that rule to refer to the gateway won't be necessary if you already have a LAN rule redirecting all internet traffic from 192.168.1.15 to the VPN, but there could be circumstances where you'd need it (such as if you configured it so that only TCP traffic from 192.168.1.15 to the VPN).

Also, you can replace 192.168.1.15 and 8.8.8.8 with Aliases to make it easier to set-up rules affecting multiple clients if you like.

Ah, nice!

Yup I've been there. 😉 I usually enter devices as a static mapping even they are using statically configured IPs. That way they still resolve and you can't accidentally reuse the IP.

@Antibiotic I just wanted to follow up on this one. I found out the problem was that I had not changed the gateway for the firewall rule, which is listed in the advanced settings. After changing the gw, voila. Darn stupid mundane details...i swear.....

Anyway, thank you for helping....

I'll answer myself :

So my understanding of why route was not add was because the tunnel was not able to completly connect, and this make sense (still a guess though...)
After upgrading client to 24.11 the tunnel succeed to connect to the server (wich is still in 22.05)

Finally im not really sure what was the root, because i had many pfsense in 22.05 with SSL/TLS tunnel working fine so my guess is, it was a mix of slow link and version, and was not related to my conf.

hope this will help others

@viragomann Hi , thanks but it was not a issue with Pfsense but rather I had not configured my vlans on my cisco switch properly.

@Bambos
When stating an alternative hostname, pfSense generates a SAN certificate. There is no reasonable case for me to do this with a user certificate, however.

The CSO check verifies only one value, either the common name of the client certificate or the username, not both. As mentioned, which one to use can be set in the server settings.

@ElaineNav

I answer my self it could be usefull for others:

After few try, i change the role of pfsense and set the server on the slower side, now the tunnel is stable. :)

@rajukarthik said in Openvpn on mac is not working:

Would prefer OpenVPN connect. Any suggestions?

Yes. Download and install it ?!
Not hard to find. Type OpenVPN connect MacOS - it's the first link.

For clarity, I reset the client pfsense box to factory defaults.