OpenVPN - Connecting to specific host networks

[viragomann]

@m0snr
Seems to be set up all right as you described it, but possibly there are mistakes in details. Wrong rule order for instance?
Should be something with the rules, I think.
But without getting detailed insight in your set up, it's hard to say.

You may post screenshots of your rule sets and vpn setting so that we can verify.

[M0SNR]

@viragomann Thanks for your reply. I think I'm going in the right direction and the rules in my mind seem to be in the right order although there's probably something I've missed.

Here are the interface definitions that I've set up -

and here are the rules that I've set for the Guest_VPN interface -

The rules for the OpenVPN are -

So I've disabled the rule that the Wizard added.

And the four rules themselves -

Here are the VLAN entries -

I think I've captured everything - if there are any other screenshots thay may be helpful, please let me know.

[M0SNR]

@m0snr I've also found that disabling the allow anywhere rule for the OpenVPN interface prevents any routing from the Guest_VPN interface, so that seems to be overriding the rules for the Guest_VPN interface.

This is the rule for the OpenVPN interface -

What I'm also unsure of is how I can get Guest_VPN clients to use the 192.168.2.1 gateway.

[bingo600]

@m0snr

I have NO active rules on the "Global/Master" OpenVPN interface.
I have defined "Sub interfaces" for all my OpenVPN servers.

All my rules are on the "Sub interface(s)" , created via "Interface" ... In your case Guest_VPN

The rule for RY on the OpenVPN (Global/Master) IF , isn't that allowing Any to Any ??
That would match your Guest range too.

I'd add the RY IF as a subinterface too (openvpns1) , and remove any rules from the OpenVPN IF.

Then Add the RY permit Any Any to the new RY "sub interface".

/Bingo

[viragomann]

@m0snr said in OpenVPN - Connecting to specific host networks:

I've also found that disabling the allow anywhere rule for the OpenVPN interface prevents any routing from the Guest_VPN interface, so that seems to be overriding the rules for the Guest_VPN interface.

The OpenVPN tab is an implicitly generated interface group. It appears as soon as there is any OpenVPN instance set up on pfSense, maybe server or client, and it includes all instances.

Accordingly to the pfSense rule processing order, rules on interface groups have priority over rules on the included interfaces.
So you have either to disable / remove that rule (you wrote you did) or edit it so that it doesn't match to the traffic from the guest vpn network.

[M0SNR]

I've set up individual interfaces for both of my VPN connections and disables the global rules for OpenVPN.

And set up the rules for the Guest VPN -

The default gateway for the Pfsense system is 192.168.10.1 and that is where my network resides. The other two 192.168.2.0/24 and 192.168.3.0/24 were added afterwards.

The firewall rule to prevent access to the 192.168.3 and 192.168.100 work fine. I just cannot block .10 - however I configure the rules. It's as if the tunnel is NATted(?) from 192.168.71.0/24 to the .10 network because it's the default gateway? I'm far from an expert on firewalls and I'd have thought that the tunnel would be on .71 and preventing it seeing the .10 network would be a breeze. It won't work on my main VPN either when I tried it as a test. Maybe there is something fundamental that I'm missing. Here is the block rule -

I've also tried setting LAN network rather than 192.168.10.0/24. I thought I knew what was going on here :(

[viragomann]

@m0snr said in OpenVPN - Connecting to specific host networks:

and disables the global rules for OpenVPN.

Your screenshot above shows a rule on the OpenVPN tab allowing any to any:
https://forum.netgate.com/assets/uploads/files/1618093211625-screenshot-from-2021-04-10-23-08-55.png

Now what?

[M0SNR]

This post is deleted!

[M0SNR]

@viragomann The two default rules in the OpenVPN tab are both disabled -

My understanding (which may be wrong!) is that the rules are processed in sequence from the top - so for the Guest_VPN, if the address matches the security net, then it will be blocked, if it's address matches the 100.1 network it will be blocked and if it's on the main (LAN) .10 network it will be blocked, and then anything else will be allowed, this is primarily for net access. So the .10 request will be blocked before it gets to the allow all rule.

These are the rules that I have set for the non-VPN Guest network (.2) -

I'm on this network now - 10.1 and 3.1 are unreachable as expected.

[viragomann]

@m0snr said in OpenVPN - Connecting to specific host networks:

The two default rules in the OpenVPN tab are both disabled -

Yeah, but the screen above shows one enabled.
Is it working now as desired?

My understanding (which may be wrong!) is that the rules are processed in sequence from the top - so for the Guest_VPN, if the address matches the security net, then it will be blocked, if it's address matches the 100.1 network it will be blocked and if it's on the main (LAN) .10 network it will be blocked, and then anything else will be allowed, this is primarily for net access. So the .10 request will be blocked before it gets to the allow all rule.

All correct.

Hint: For the sake of security it's recommended to block all and allow only specific sources or destinations.

So if you want to block all incoming traffic on an interface to a specific destination you should better use "any" as source.

Also instead of blocking all your internal networks specifically, I'd block the whole RFC1918 range and allow only specific destinations if needed.
To do so you can add an alias including all RFC1918 network and use it as destination in the block rule. So with this rule you will still be safe if you do some changes on your network.

[M0SNR]

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