@notahacker
The policy routing rule directs any matching traffic to the VPN server.
So this will also include DNS, however, your computer might been configured to use the PiHole for name resolution.

So if you want to use your PiHole on this machine you have to add an additional firewall rule without a stated gateway above of the policy routing to allow the DNS access.
However, this will result in DNS leaks, cause with this the DNS goes out the WAN interface.
You can only avoid DNS leaks by directing DNS requests from the concerned computer over the VPN.

@airwave said in Upgrade to 21.02 -> Client Cert on LDAP server no Longer Accepted:

I updated to 2.5.1 AND now it works and a connection is established and traffic is been delivered, but ONLY ONCE after openvpn service start.
When I then disconnect and reconnect, again I get a connection, but the communication / traffic (ping etc.) is not working. Only in the first connection traffic works. When I restart the openvpn service then, its again working once...

Hi all,

I tested a bit deeper and found out, that the attribute "explicit-exit-notify" in the openvpn client configuration seems to remove my issue with "no communication on reconnect".

So then I guess this problem is fixed with 2.5.1 and explicit-exit-notify.

Cheers

@stellir said in OpenVPN is setup and connecting but no access to local shares.:

@viragomann said in OpenVPN is setup and connecting but no access to local shares.:

add a pass rule to the Windows firewall for the VPN tunnel network

Any direction to accomplish this would be appreciated. The wizard created a Pass rule for the OpenVPN on port 1194 so what else is needed.

You need to do the on your Windows 10. This one:

Ok I disabled the firewall on the Windows 10 computer hosting the files

That's not the topic of this forum and I'm not sitting on a Windows currently. But there is an option to add firewall rules to it, something like "firewall advanced settings". Add an allow rule for the source of the VPN tunnel network, maybe you want restrict ports or simply allow any.

@viragomann Thanks for your help, sir! I really appreciate it. I am unsure as to how or why, but changing the connection to UDP seems to have fixed it. I don't know why or whether this alone was the issue, but the rules are the same and it now just works. It has also been re-booted a few times.

All the best, Richard.

@heliocoeur said in PfSense (2.3.3) Hangs on boot with invalid OpenVPN password:

vpn > openvpn > client

and put a password to the user.

if needed put a password to the same user in system > user manager

that is the solution ..many thanks to heliocoeur

@bob-dig said in Port forwarding on OpenVPN interfaces is broken on 2.5.1:

Probably this: https://redmine.pfsense.org/issues/11805

Yeah that's probably the same bug :)

@shamsali222

When you use DHCP to provide an address, you can go into Status / DHCP Leases to find the assigned address. You can then convert that MAC address to a static lease with whatever address you choose, provided it is not within the DHCP pool.

@ddbnj
Basically it doesn't matter, where you add the rules, however if you have already assigned an interface, I'd prefere the interface tab. It's quite simpler.
For instance, if you add a block rule you can use any at source without affecting the other VPN instances.

Furthermore if there is an incoming traffic from a public source on an OpenVPN interface (forwarded from the remote site) you have to care, that there is no rule on the OpenVPN tab mathing it. Otherwise responses are not routed back properly.

@viragomann the 192 address is my local LAN making the requests.

"So again, my assumption is that the remote site is missing the route back to this LAN IP and so its not possible to direct its packets correctly into the VPN, instead it will send them out to its default gateway."

I agree that if the server side was missing the route back, it wouldn't know what to do with the traffic and how to send it back, but the key bit I'm not getting is that shouldn't I see that traffic emerging from the tunnel on the VPN side, the bottom tcpdump on the second screenshot. I fully get why I don't see any traffic coming back into pfSense from the VPN side, because no traffic is sent back, but I don't get why I don't see the ICMP requests that go in on the top of the screenshot come out on the bottom. Where does that traffic go?

I'm sure you are right with what you are saying, I just want to know where the packets go missing. I thought that if they went into a tunnel they would come out the other side, even if they then got lost and the next hop sent them the wrong direction and out the wrong gateway.

The router from my ISP is setup in 'modem only' mode, it does not perform any routing or wi-fi functions, its only connection is t othe WAN port of my pfSense unit.

I run Unifi switches and access points all of which sit behind the pfSense unit.

I am guessing that since I only have the one WAN IP, once the VPN tunnel is opened from the pfSense firewall, the VPN IP is now perceived by all clients to be their external IP, whereas previously when I ran a VPN on an individual device, the VPN IP only applied to that single device.

In effect running a PIA VPN tunnel from the pfsense firewall can only act as a 'whole house' VPN, regardless of what firewall rules I may use.

I have also noticed a severe drop in bandwidth when using the PIA OpenVPN tunnel on the pfSense firewall.

All tests were performed from my iMac desktop:

Test Case down/up No VPN 386/20.8 pfSense + London 152/19.8 pfSense + Southampton 205/19.4 VPN app + London 303/19.5 VPN app + Southampton 293/19.6

The PIA app based firewall is using wireguard, although until recently it was using OpenVPN, the results using the app are usually within 50-60Mb/s of the figures with no VPN (they are a bit down today), but never as bad as those shown for OpenVPN on pfSense.

Looks like I may be sticking with local VPNs for now.

For comparison, I ran a speedtest from my media server using a wireguard based PIA tunnel to the same London server and recorded speeds of 317/19.6 with the VPN tunnel and 322/21.1 without. The media server is connected to the same switch as my iMac, both with 1m cables.

@tunge2

According to the above referenced post , and the redmine inside that post.
It seems that the issue was introduced in 2.5

/Bingo

Show as the outbound NAT rules and check, that every client got a different private IP address from your VPN provider. If they share an address, it will not work.

@viragomann Thanks I'll try this tomorrow and post the screenshots.

I just wanted to follow up on this, in case anyone else runs into the same problem.

The way I was doing it is for a 1:1 VPN. I solved it by following these instructions: https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-tls.html

A bit more complicated setup, but it's now working.

@jagradang
Hi, I am not at my machine at the moment, but I found out what this issue was.
In the 'General DNS Resolver Options' , Outgoing Network Interfaces
is set to nordVPN (as per the instructions). However if you set this to WAN, it appears to work.
To be honest I am not sure what the 'real' exposure is.

Also a more advanced question, is it possible to enable UPNP at Site A such that they're applied at Site B?