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

Youtube Video

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)

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

@viragomann Thanks for the advise. It worked finally. I just have a bit of doubt. After I created /30 and not added any remote networks, the server could not get an IP. It was fixed by adding remote IP on both ends which is strange cause if I only want to allow outbound IP without any inter-private routing, i don't need to specify it. This worked for shared-key setup but not on SSL/TLS.

I followed this Youtube tutorial https://www.youtube.com/watch?v=8f13lfnEKY8
and I believe it is the same as your setup.

#1 Pfsense running 2 openvpn server instances (has corresponding network as remote network)
#2 Pfsense running 1 openvpn client to Pfsense #1 (has both other networks as remote network)
#3 Pfsense running 1 openvpn client to Pfsense #1 (has both other networks as remote network)

I wasn't able to ping from the Pfsense #2 to #3 nor vice versa.
Both #2 and #3 were able to ping to #1

But then I noticed it was only the Pfsense itself.
Clients on Pfsense #3 could reach clients on Pfsense #2.
Clients could also ping all pfsenses....
Client pfsenses can't ping clients on other network.

In fact this is the main purpose of the site-to-site-to-site VPN, so I have it working now.

I now have a few questions:

Is this behaviour to be expected? What do I need to do so #2 and #3 themselves can ping each other? Should I consider this a bug? Is this a recommended setup? I have a feeling it isn't as #2 and #3 can't reach each other anymore if #1 is failing. Do I solve that single point of failure by creating a server instance on either #2 or #3, and let the other client connect to it??

@khris2fer

No, that relies on being within the same subnet, as multicasts are used, which do not pass through routers.

@jimp I have tried at least a dozen different ways to get DCO to work and I can never get any traffic to flow once I switch the tunnel to DCO. I have tried taking existing tunnels and switch them to DCO, build a new one from scratch and tried DCO on both the client, server and both at the same time. I'm not sure if I am running into the iroute issue or what the problem is, the documentation is all for the non-DCO implementations and doesn't really apply here.

One scenario I am trying to make work is a remote site connects to central hub, central hub has many sites connecting to it and uses DCO with QAT offload. Once the tunnel establishes, no traffic will flow thru the tunnel. I have tried policy based routing and static routes but neither seems to be working.

I even tried setting up a very basic road-warrior VPN setup with no fancy routing at all, and the clients can't even ping across the tunnel to the VPN interface IP.

Scouring the internet for working setups has not net any results so I was wondering if there is any documentation from netgate about how to actually do it "properly".

Thanks!

I still haven't figured out why this is happening. The only update I have is that I've also tested this on macOS using the official openVPN client and I had the same results: perfect upload speeds (to the server) and terrible download speeds (from the server).

I don't know what else to try at this point.

Hi @viragomann,
Where can I see VPN IP? Because only PfSense client (Branch Office) connected to PfSence Server (Head Office).
No I can not ping LAN IP from Head office.

I can ping only Pfsense which is in the BranchOffice.

Yes I set it to /30

Yes both sides are green.

Regards,
Mucip:)

@kallabaz I am not sure, but I think that OpenVPN has a licencing scheme for both multiple servers and multiple users (?). Again, I am for no way sure, but I always had problems with openVPN. Maybe just use IPsec or wireguard if you are the only one remoting?

@wn7ant Sorry for 3 replies in a row... I tend to write as I see. But,
2dc8ce97-7897-4096-af84-3821fbdc1ac0-image.png
this right here could be your issue, seeing as you might be behind another (CPE, yes, but) firewall.
That means NAT with pfsense behind it.
That means that you are not using a Public IPv4.
Can't do OpenVPN reliably behind NAT, at least not with firewalls like PfSense as clients.

Also, because of the way IPv4-NAT and IPv6-GUAs are routed, you might be having additional problems (and latencies) because of double NAT and a single IPv6 (/128) address on the WAN interface.
WAN needs at least a /64 IPv6 subnet to perform either DHCPv6 or do Prefix Delegation on the ifaces downstream (eg, LAN).
In the case of prefix delegation (which is strongly suggested), you need subnets larger than /64 (/60, /56, /52, /48).
It's usually /48, but that is not a given (my ISP hands out /56's).

If your environment isn't a VM lab, maybe try to contact your ISP and put the CPE modem/AC/router in PPPoE (or PPPoA) passthrough mode (the CPE will still be a WiFi AC and router for any clients connected on it, like phones, TVs, PCs and such) or bridge mode (the CPE will no longer be a router or a WiFi AC, but just a bridge for PFSense, the ISPs own VoIP and/or TV). That way, you can
715ded1f-d443-402b-8b56-2a0f536ed32f-image.png
and here you usually you need your username and pass tied to your subscription account (you get those from your ISP)
192e4609-eba1-486c-bfce-27f5c37692bc-image.png
In business environments, most ISPs give a static /32 IPv4 for free as an option (not advertising it, though).
In that case, you might get them to give you a static /32 IPv4 for pfsense (through PPPoE/A passthrough) AND a dynamic (usually CG-NATed) /32 IPv4 for the CPE.

Also, if you are situated in a VM lab, you not only need to give pfsense a physical interface (network card) passed-through by the hypervisor, but you also need this interface to NOT be behind a CPE (router-modem or just router). If that is the case, you will encounter a lot more problems down the road. As long as you do not do that, you are under the thumb of the ISP (they control the CPE's firewall) and must accept the limitations that come with this type of setup (UDP connections are notoriously unfriendly to NAT, some applications depend on a stable internet-facing port, you might be getting a CG-NATed address on the CPE, which makes any client behind pfsense triple NATed...)

@mikey_s I haven’t had the opportunity to try it yet but per https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/dco.html:

“Thus, DCO is beneficial even when only one endpoint is capable of DCO. That said, tunnels employing DCO on all peers will see the most benefit. With DCO on only one peer the performance improvement can still be notable but not as significant as the gains with DCO support on both endpoints.”

That page also says it’s (still) experimental.

@viragomann Thank you so much. Yes. I did setup the gateway monitoring and indeed that was the fix. Need to set the default gateway to the multiwan gateway group i created.

@thomas_br Really wish there was a real solution for this. Sure I need to upgrade my device, but I also have a problem right now that Netgate is aware of but has made no effort to resolve without further service impact.

A few weeks ago I went through and tested LDAP auth with extended query in a few different LDAP setups with/without RFC2307 groups and updated the docs with better info on that and using multiple server entries limited by groups for these sorts of purposes.

If you haven't reviewed the docs recently, look them over again.

https://docs.netgate.com/pfsense/en/latest/usermanager/ldap.html

https://docs.netgate.com/pfsense/en/latest/troubleshooting/authentication.html

Also I highly recommend using an LDAP browser such as Apache Directory Studio to test your queries and settings to dial in getting the results you want.

@jims
The traffic doesn't go through the WAN interface in a logical way. It is tunneled and come in on the OpenVPN interface in pfSense.
Also the traffic cannot pass through a LAN device by default. This would require special settings on the device. Since I assume, you control this device, you can be sure that they are not done.

The whole security depends on the VPN authentication, regardless how you realize the access to the LAN devices. The server is under your control, you say, so use strong password and client certificates and you're safe.
On pfSense you can additionally configure, what the clients are allowed to access.

To answer this myself - I do not think OpenVPN user authentication failures from the pfSesne local database causes account lockout. SSH and Web UI failed logins will cause the source of the connection to be temporarily added to the block list.

@jimp just answered this (as I type) to say it does not lockout the local database users.

I have found, with help from Lawrence Systems videos (Tom L is a legend, n'est pas?) I can install FreeRadius package, and enable mobile one-time-passwords, add Radius users with OTP and get two benefits - disable accounts that fail to authenticate AND MFA/OTP.

This satisfies UK Cyber Essentials, and I have a much stronger login process. Today is a good day.

Solved it, and now I can ping LAN IPs and do RDP etc. It was the devices on my LAN were not using the pfsense IP as their gateway, but a different gateway device. I didnt think all the target devices on the inside of the network needed the pfsence box as their gateway. It makes sence now.
Also, a gateway IP is still not present for the openVPN connection, but connection to LAN devices and to the internet is working normally despite this.

@viragomann

I appreciate your help, it pushed me in the right direction, there must indeed have been my ISP router out in the street box/head office. My WAN was using a private IP address with I assume the public IP address at my ISP router.

I believe that traffic was hitting my Pfsense router but the outbound traffic was not being NAT'd correctly by the ISP router.

Anyway, I upgraded to have a public IP on my router which resolved the issue.

@chpalmer

That is a very common problem caused by the need to use NAT & RFC1918 addresses with IPv4.

Back in the early 90s, when I first started using the Internet, I had a static address, I was using SLIP, which required manual configuration. In 1997, I started at IBM, and had 5 static, public addresses, 1 for my own computer and 4 for testing. A couple of years later, when I got a cable modem and built a firewall/router on Linux, I ran into my first problem caused by NAT. FTP broke! Back then, command line FTP was used and NAT broke active mode FTP. At the time, FTP clients generally didn't support passive mode. These days, things like VoIP and some games require a hack called STUN, to get around the problems caused by the hack called NAT.

The answer to this is IPv6!

@sfermindi bear in mind those instructions are from a release from 2018. Things do change.

@owlbear

If you don't mind a video, you can get one form the source :

Configuring OpenVPN Remote Access in pfSense Software

@viragomann you had it right they didn't show up because there were no user certificates. So my configuration wasn't complete.

@jims Spoke too soon. It now shows it reconnects but all the traffic isn't passed. I can get to one of my PCs through the VPN but can't get to others, even after rebooting pfsense. Thought it was something to do with the other PC so tried another and even a printer than has a web page and no go. Not sure what to check now...

I managed to get it all working
using a combination of Client specific overrides and natting on the router

I switched the OpenVPN server from TAP to TUN, set the IPv4 Tunnel Network to a different subnet and everything works now.

@viragomann Yeah I'm aware of all that. OpenVPN gives the pfsense VPN IP as DNS server. It works with anything public. It doesn't work with anything that should resolve to LAN IP. Doesn't work with FQDN. From the LAN side same DNS server does resolve FQDN. The remote machine is using the same domain as pfsense and what the LAN machines get via DHCP. But again I tested FQDN so even if the remote machine didn't know the domain it should get the correct response from the DNS server.

I get what NAT does. I don't see why I'm having to use it. pfsense sees both the LAN and VPN networks as it's own literally everywhere I look. Usually with pf you are fighting to keep traffic from being able to go between different networks.

@bp81

It all depends also on what are the workstations are doing through the tunnels! As an example, you have 20 tunnels
and heavy load on (through) them and this is like 50
tunnels and more with only some small traffic through them.

No one of us is able to answer this question without knowing what traffic and how much traffic is running through that tunnels.

@peterlinux
If there is only a single client connected to the server, the CSO is not necessary in fact. But in this case you have to use a /30 tunnel network and set the "remote networks" on both site, server and client.