Client-specific access rule issue

Need help configuring your VPN? Just post here and you'll get that help.
Forum rules
Please use the [oconf] BB tag for openvpn Configurations. See viewtopic.php?f=30&t=21589 for an example.
Post Reply
RBE
OpenVpn Newbie
Posts: 6
Joined: Fri Jan 28, 2022 7:43 am

Client-specific access rule issue

Post by RBE » Fri Jan 28, 2022 8:44 am

Hi All.

I have been trying to add client-specific rules and access policies as per the 2x HowTo to my existing OpenVPN setup, but am having great difficulty getting it to work.

In short, I have several VLANs on my home network, three of which are 192.168.10.0/24, 192.168.20.0/24, and 192.168.30.0/24. Each VLAN has a different class of user with different rights, and I am attempting to use CCD files to force clients onto a matching 10.8.xx.0/24 tunnel subnets so that I can apply appropriate firewall rules. My OpenVPN server is a Ubiquiti Edgerouter 4 which runs VyOS, and the relevant section of my router config file is:

Server Config

openvpn vtun0 {
mode server
openvpn-option "--keepalive 10 120"
openvpn-option "--user nobody"
openvpn-option "--group nogroup"
openvpn-option "--persist-key"
openvpn-option "--persist-tun"
openvpn-option "--tls-server"
openvpn-option "--remote-cert-tls client"
openvpn-option "--tls-crypt /config/auth/tls-crypt.key"
openvpn-option "--client-config-dir /etc/openvpn/ccd"
openvpn-option "--ccd-exclusive"
openvpn-option "--route 192.168.10.0/24"
openvpn-option "--route 192.168.20.0/24"
openvpn-option "--route 192.168.30.0/24"
server {
subnet 10.8.0.0/24
push-route 192.168.10.0/24
push-route 192.168.20.0/24
push-route 192.168.30.0/24
name-server 192.168.10.1
}
tls {
ca-cert-file /config/auth/ca.crt
cert-file /config/auth/rt1.crt
dh-file /config/auth/dh.pem
key-file /config/auth/rt1.key
}
description VPN
}


The OpenVPN client I am using for testing is a laptop running Debian:

Client Config

client
dev tun
proto udp
remote x.x.x.x 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
mute-replay-warnings
ca /etc/openvpn/ca.crt
cert /etc/openvpn/mech1129.crt
key /etc/openvpn/mech1129.key
remote-cert-tls server
tls-crypt /etc/openvpn/tls-crypt.key
verb 3
mute 20


The CCD file for this client contains the following:

Code: Select all

ifconfig-push 10.8.20.5 255.255.255.0
When connecting, client output is as follows:

Code: Select all

Fri Jan 28 21:23:54 2022 TUN/TAP device tun0 opened
Fri Jan 28 21:23:54 2022 TUN/TAP TX queue length set to 100
Fri Jan 28 21:23:54 2022 /sbin/ip link set dev tun0 up mtu 1500
Fri Jan 28 21:23:54 2022 /sbin/ip addr add dev tun0 10.8.20.5/24 broadcast 10.8.20.255
Fri Jan 28 21:23:54 2022 /sbin/ip route add 192.168.10.0/24 via 10.8.0.1
Error: Nexthop has invalid gateway.
Fri Jan 28 21:23:54 2022 ERROR: Linux route add command failed: external program exited with error status: 2
Fri Jan 28 21:23:54 2022 /sbin/ip route add 192.168.20.0/24 via 10.8.0.1
Error: Nexthop has invalid gateway.
Fri Jan 28 21:23:54 2022 ERROR: Linux route add command failed: external program exited with error status: 2
Fri Jan 28 21:23:54 2022 /sbin/ip route add 192.168.30.0/24 via 10.8.0.1
Error: Nexthop has invalid gateway.
Fri Jan 28 21:23:54 2022 ERROR: Linux route add command failed: external program exited with error status: 2
Fri Jan 28 21:23:54 2022 GID set to nogroup
Fri Jan 28 21:23:54 2022 UID set to nobody
Fri Jan 28 21:23:54 2022 Initialization Sequence Completed
Also from the client:

Code: Select all

$ ip addr
12: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 10.8.20.5/24 brd 10.8.20.255 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::b3eb:9104:f2e4:a615/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

$ ip route
default via 192.168.175.153 dev enp0s29u1u1 proto dhcp metric 100 
10.8.20.0/24 dev tun0 proto kernel scope link src 10.8.20.5 
169.254.0.0/16 dev enp0s29u1u1 scope link metric 1000 
192.168.175.0/24 dev enp0s29u1u1 proto kernel scope link src 192.168.175.56 metric 100 
Now, I understand that the issue has something to do with gateways, but I am very confused as to how to implement a solution. If I look at the router GUI, the IP address listed for the vtun0 interface is 10.8.0.1/24. What is the relationship between this IP address and the 10.8.20.5/24 address the client has received? If anyone is able to point me in the right direction I would really appreciate it, as the more I read the more confused I become.

User avatar
TinCanTech
Forum Team
Posts: 10693
Joined: Fri Jun 03, 2016 1:17 pm

Re: Client-specific access rule issue

Post by TinCanTech » Fri Jan 28, 2022 6:12 pm

If I were you, I would start by learning how to setup a basic VPN first.

RBE
OpenVpn Newbie
Posts: 6
Joined: Fri Jan 28, 2022 7:43 am

Re: Client-specific access rule issue

Post by RBE » Fri Jan 28, 2022 6:51 pm

I have a basic VPN setup going already that gives me access on the 192.168.20.0/24 subnet. The only thing that I have added to that setup is the code to enable per-client access, specifically the additional routes and push-routes.

User avatar
TinCanTech
Forum Team
Posts: 10693
Joined: Fri Jun 03, 2016 1:17 pm

Re: Client-specific access rule issue

Post by TinCanTech » Fri Jan 28, 2022 7:24 pm

RBE wrote:
Fri Jan 28, 2022 6:51 pm
I have a basic VPN setup going already that gives me access on the 192.168.20.0/24 subnet
Looks like it fails to me:
RBE wrote:
Fri Jan 28, 2022 8:44 am
Fri Jan 28 21:23:54 2022 /sbin/ip route add 192.168.20.0/24 via 10.8.0.1
Error: Nexthop has invalid gateway.
Fri Jan 28 21:23:54 2022 ERROR: Linux route add command failed: external program exited with error status: 2
The reason that it fails is because your client CCD is incorrect for the --topology you are using.

However, if you want to use VLAN tagging then you need --dev tap instead.

See https://build.openvpn.net/man/openvpn-2 ... vpn.8.html for the options above.

RBE
OpenVpn Newbie
Posts: 6
Joined: Fri Jan 28, 2022 7:43 am

Re: Client-specific access rule issue

Post by RBE » Fri Jan 28, 2022 11:56 pm

For what its worth, the previous working server config was as follows:

Previous Working Server Config

/* vtun0 is the OpenVPN tunnel. */
openvpn vtun0 {
mode server
openvpn-option "--keepalive 10 120"
openvpn-option "--user nobody"
openvpn-option "--group nogroup"
openvpn-option "--persist-key"
openvpn-option "--persist-tun"
openvpn-option "--tls-server"
openvpn-option "--remote-cert-tls client"
openvpn-option "--tls-crypt /config/auth/tls-crypt.key"
server {
subnet 10.8.0.0/24
push-route 192.168.20.0/24
name-server 192.168.20.1
}
tls {
ca-cert-file /config/auth/ca.crt
cert-file /config/auth/rt1.crt
dh-file /config/auth/dh.pem
key-file /config/auth/rt1.key
}
description VPN
}


with client details:

Code: Select all

$ ip route
default via 192.168.239.240 dev enp0s29u1u1 proto dhcp metric 100 
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.2 
169.254.0.0/16 dev enp0s29u1u1 scope link metric 1000 
192.168.20.0/24 via 10.8.0.1 dev tun0 
192.168.239.0/24 dev enp0s29u1u1 proto kernel scope link src 192.168.239.56 metric 100 

$ ip addr
18: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 10.8.0.2/24 brd 10.8.0.255 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::ebf3:91cb:315f:8164/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever
I was hoping that the addition of client-specific access would be a simple change to the existing working config, but this has turned out to not be the case. I will do some reading around your --dev tap topology suggestion and see if I can figure out what needs to be done.

User avatar
openvpn_inc
OpenVPN Inc.
Posts: 655
Joined: Tue Feb 16, 2021 10:41 am

Re: Client-specific access rule issue

Post by openvpn_inc » Sat Jan 29, 2022 1:03 am

RBE wrote:
Fri Jan 28, 2022 8:44 am
I have been trying to add client-specific rules and access policies as per the 2x HowTo to my existing OpenVPN setup, but am having great difficulty getting it to work.

In short, I have several VLANs on my home network, three of which are 192.168.10.0/24, 192.168.20.0/24, and 192.168.30.0/24. Each VLAN has a different class of user with different rights, and I am attempting to use CCD files to force clients onto a matching 10.8.xx.0/24 tunnel subnets ...
But you only configured ONE such subnet, as I can see: 10.8.0.0/24!
RBE wrote:
Fri Jan 28, 2022 8:44 am
so that I can apply appropriate firewall rules.
And there are lots of ways to do this. You can subnet within a /24.
RBE wrote:
Fri Jan 28, 2022 8:44 am
My OpenVPN server is a Ubiquiti Edgerouter 4 which runs VyOS, and the relevant section of my router config file is:
I'm not familiar with this syntax so I can't support it, just going to cut out everything but the single /24 you apparently gave it:
RBE wrote:
Fri Jan 28, 2022 8:44 am
Server Config

-snip-
server {
subnet 10.8.0.0/24
-snip-


The OpenVPN client I am using for testing is a laptop running Debian:

Client Config

client
-snip-


The CCD file for this client contains the following:

Code: Select all

ifconfig-push 10.8.20.5 255.255.255.0
You can't assign an address outside what the server has to give!
RBE wrote:
Fri Jan 28, 2022 8:44 am
When connecting, client output is as follows:

Code: Select all

Fri Jan 28 21:23:54 2022 TUN/TAP device tun0 opened
Fri Jan 28 21:23:54 2022 TUN/TAP TX queue length set to 100
Fri Jan 28 21:23:54 2022 /sbin/ip link set dev tun0 up mtu 1500
Fri Jan 28 21:23:54 2022 /sbin/ip addr add dev tun0 10.8.20.5/24 broadcast 10.8.20.255
Fri Jan 28 21:23:54 2022 /sbin/ip route add 192.168.10.0/24 via 10.8.0.1
Error: Nexthop has invalid gateway.
Fri Jan 28 21:23:54 2022 ERROR: Linux route add command failed: external program exited with error status: 2
-snip-
Also from the client:

Code: Select all

$ ip addr
12: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 10.8.20.5/24 brd 10.8.20.255 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::b3eb:9104:f2e4:a615/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

$ ip route
default via 192.168.175.153 dev enp0s29u1u1 proto dhcp metric 100 
10.8.20.0/24 dev tun0 proto kernel scope link src 10.8.20.5 
169.254.0.0/16 dev enp0s29u1u1 scope link metric 1000 
192.168.175.0/24 dev enp0s29u1u1 proto kernel scope link src 192.168.175.56 metric 100 
Now, I understand that the issue has something to do with gateways, but I am very confused as to how to implement a solution. If I look at the router GUI, the IP address listed for the vtun0 interface is 10.8.0.1/24. What is the relationship between this IP address and the 10.8.20.5/24 address the client has received? If anyone is able to point me in the right direction I would really appreciate it, as the more I read the more confused I become.
Your server (via CCD) told the client to assign itself an address which the server can't handle. Take out the --ifconfig or change it to an address in the server's tun network. Then compare to see what your addresses and routes look like. You're missing the point-to-point connection to the server's tun address.

If you insist on the multiple /24 networks, you have to give the server a big enough network to include them all. 10.8.0.0/19 would include all the way up to 10.8.31.255. And you won't want all of that to be in the server's dynamic address pool, so look up the --server macro in the manual. I can't tell you how to encode that in Ubiquity syntax, of course.

regards, rob0
Image OpenVPN Inc.
Answers provided by OpenVPN Inc. staff members here are provided on a voluntary best-effort basis, and no rights can be claimed on the basis of answers posted in this public forum. If you wish to get official support from OpenVPN Inc. please use the official support ticket system: https://openvpn.net/support

RBE
OpenVpn Newbie
Posts: 6
Joined: Fri Jan 28, 2022 7:43 am

Re: Client-specific access rule issue

Post by RBE » Sat Jan 29, 2022 10:36 pm

Hi Rob.

Thanks for your reply. It turns out my understanding of subnetting was hopelessly wrong, and after much experimenting I believe I now have things working as expected. The key was to have my firewall rules gate access according to whether or not the client's IP address is part of a particular /27 subnet, ie one of:

10.8.0.0/27 (clients of which should have access to my 192.168.10.0/24 network)
10.8.0.32/27 (clients of which should have access to my 192.168.20.0/24 network)
10.8.0.64/27 (clients of which should have access to my 192.168.30.0/24 network)

Then, in the CCD file, allocate an IP address from appropriate subnet, but give it a /24 netmask so that the OpenVPN server at 10.8.0.1/24 can act as the gateway. For example, my test client should have access to my 192.168.20.0/24 network, so its CCD file contains:

ifconfig 10.8.0.34 255.255.255.224

And as expected, the firewall lets it access the appropriate network. If I change the CCD file to give the client an address from one of the other two /27 subnets, it does not have access, so I think I have it sorted - for now at least.

Post Reply