@kiokoman thanks for the tip, I have configured a bridge with linux tools (brctl) and I'm using virt-io and I thought that would be enough but it is in fact very reasonable that it would actually introduce limitations and weird behaviors like what I'm seeing, I will dig further the issue

The OpenVPN option text should probably be renamed. The engine command in OpenVPN isn't required. When it's unset then it automatically selects a device which supports accelerating whatever cipher it's trying to use.

When it's set to a specific engine, it's supposed to prefer that engine but I don't believe it's restricted to only using that engine. Since most things only have 0-1 available usable engine types, that's not so easy to test.

So really the No Hardware Crypto Acceleration line should be Use any available cryptographic hardware device or something along those lines.

Ok, if you only have a firewall rule with the OpenVPN gateway set it will force all traffic out that way which will break connectivity to the LAN.
Add a rule on the new interface above any rules with a gateway set to pass ping traffic to the LAN.

Otherwise check the firewall logs. Check the state table while you're pinging.

Steve

@Bob-Dig
thanks for the interesting hint, tagging looks like a great feature!
So basically I am tagging all (!) my current rules in the LAN section where I define which traffic is allowed and that it goes through the OpenVPN gateway.
And the I setup a rule which rejects all traffic which is tagged and goes to WAN, correct?

How do I make sure that the only connection the pfsense can do itself will be to VPN Providers DNS and OpenVPN Servers?

As far as I understand this can also be done via "floating rules":

Floating Rules can:
Filter traffic from the firewall itself
Filter traffic in the outbound direction (all other tabs are Inbound processing only)
https://docs.netgate.com/pfsense/en/latest/firewall/floating-rules.html
[...]

-Tom

Which VPN service are you using? Almost all mainstream providers offer a split tunneling feature that allows you to choose which data to send through the VPN and which not. I use PureVPN but many others like ExpressVPN offer the same with their apps.

@ddbnj said in Cannot access beyond router via OpenVPN:

10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0

Yeah that would dick it up ;)

Glad you got it sorted! Told you it wasn't pfsense ;) hehehehe

The trick is getting the person to clearly see that themselves... Which is why the sniff proves to the user, hey pfsense is doing what its suppose to be doing... Have to look elsewhere..

@JeGr said in Question on OpenVPN restricting IPs:

Actually that's one point why I'm propagating the use of FreeRadius together with pfSense' OpenVPN in RAS scenarios, as it's much easier to handle than creating CSOs based on the CN of certificates. Also it minimizes the probability to make configuration errors that would allow VPN users to access pfSense WebUI with their only-for-VPN user when using internal authorization.

Yeah it's just a bit of a pain adding the users by hand, I did pop a redmine in for a copy function in the Freeradius package a couple of years ago.

https://redmine.pfsense.org/issues/8031

@Druplex said in OpenVPN unable to contact daemon pfsense 2.4.4_3:

What would be the issue?

The OpenVPN setup, the file with parameters that makes de service == daemon run correctly, contains errors. In this case, it's the place where you setup the OpenVPN settings.
So the daemon (== service) starts, and fails to work correctly, so it stops.
The GUI, let's say 'pfSense', can't contact the daemon, so it tells you what happens.

Btw : to have the OpenVPN server logs telling you what's right and what's wrong, think about putting the "Verbosity level" to 3 or 4.

Then go here :

9f1f9c6e-1512-44d7-a1d8-b844f75561a4-image.png

@JKnott
To be really honest...
A cosmic thing. Apparently not all VPN servers I've added (as client) are handing out ULA's. So on my dashboard it just looked sh*t.
Plus my OCD was hyping over this. ;-)

I just want one standard. So all three should give me an ULA or not.
Not just one.

In order for your roadwarrior clients to access resources @ site B, two things need to happen:

Site A's road warrior clients need to know that site B's LAN subnet should be routed down the tunnel Site B needs to know where to send the return traffic for site A's road warrior clients

Based on the above, the following adjustments should be made to the configs:

Site A:

Road Warrior config should have "192.168.20.0/24, 192.168.10.0/24" on the IPv4 Local network(s) line. (Remove 10.0.20.0/24).

Site B:

Re-verify the site-to-site config has "192.168.20.0/24, 10.0.20.0/24" on the IPv4 Remote network(s) line

Once the site-to-site tunnel is re-established and the clients re-connect, you should be good to go.

@paul-heidenreich-0
Outbound NAT doesn't work with policy-based IPSec tunnels. You have to do the NAT inside IPSec.
It should work with VTI IPSec, however.

If you have already a phase 2 to for the NAT-IP or subnet at the remote side, an additional is not needed in most cases.

You have always have to add the remote networdk to the "local networks", no matter if you use BINAT or outbound NAT.

That's correct. But you didn't mention, that you have already done this.

@johnpoz said in Same ip subnet for two VPN:

Some other advice 192.168.1 is not a good choice to be honest.. This is very very common - say your at a starbucks or something needing to vpn in to your site and they are using 192.168.1 locally.. Now you have a problem.. Client thinks that your server 192.168.1.100 for example is just local - and won't send it down the tunnel to get to it.

Yep, I had that problem years ago when I was staying at hotels. That's why I moved my LAN to 172.16.0.0. I have only seen that used elsewhere once.

the routing table now is the same ?
maybe it was something else on the configuration

Why do you use a /24 net for a site-2-site. A /30 will be the better choice here.

@Cricco95 said in OpenVPN site2site not working:

Trying to ping VPN server interface on 10.8.0.1:

You did the ping from WAN IP. Don't know what your WAN is, but you may miss the route.

What it you do a ping from LAN?
If it works, try a ping from LAN to the remote LAN IP of the server.

Added to what @NogBadTheBad said :

Start up a new OpenVPN server on - example - port 1195.
Assign this user - his credentials - to this VPN.
Assign the OpenVPN interface of this instance to an Interface.
Now you can use this firewall for this interface to fine-grain the access on IP "destination".

When a user comes in using a VPN, he can access - typically - your LAN(s). But all devices on these LANs have their own access codes.
The server your user should access has it's own user privileges set up, right ?

Btw : put your server on a DMZ ....

@EFP-TechTeam said in pfSense OpenVPN site-to-site client dies every day or two.:

The logs don't give a lot of clues.

What do they say?