Apparent VPN server/client conflict

[keeka]

When I configured openvpn server (merlin and john's fork) using the default subnet of 10.8.0.0/24, I found I was unable to reach LAN clients (192.168.0.0/24) from a vpn client.
Using another subnet in the vpnserver details webpage, such as 10.1.0.0/24 (or any 192.168.X.0/24 network other than the existing LAN), solved this for me.

Having changed the subnet from the default then saving, I noticed values (not exposed in the web UI) that refer to 10.8. addresses:
vpn_server_local=10.8.0.1
vpn_server1_local=10.8.0.1
vpn_server1_remote=10.8.0.2
vpn_client1_remote=10.8.0.1
vpn_client1_local=10.8.0.2
vpn_server_remote=10.8.0.2

I'm a long way from understanding how the firmware achieves what it does but I would like to understand better.

I'm confused as to why the default 10.8.0.0 vpn_server1 subnet appears to 'overlap' vpn_client1 config values above. Same goes for server2 vs client2.
Also, when I change vpn_server1 subnet, why the values above remain unmodified?

I notice that 10.8.0.0 addresses are used extensively and don't understand why/how they co-exist in various places!
All I know, from experiment, was that moving vpnserver subnet from the default 10.8.0.0/24 allowed clients to reach the LAN beyond the router.

Any insight/tuition would be appreciated!
Many thanks.

 

[agilani]

In networking, ip addresses are like phone numbers and part of it identifies the network and part of it identifies the host and therefore must be unique. You can't have two different people with the same mobile phone number can you? Ip addresses are the same.

Part of the addresses specified by rfc1918 are used as you would private extensions. Meaning like a private phone extension they are not publicly accessible. These addresses are used by multiple people for private use. But similar to private extensions, they can only be addressed uniquely when they don't overlap or they are translated to public addresses.

this is just some very basic information. If you really want to know more, study up on RFC1918.

 

[ColinTaylor]

@agilani I suspect the OP already knows about IP addresses, that wasn't his question.

@keeka Do you have both the VPN server and VPN client enabled on the router at the same time? If not then it's an academic question as the client's address/subnet won't exist.

 

[keeka]

@agilani I suspect the OP already knows about IP addresses, that wasn't his question.

@keeka Do you have both the VPN server and VPN client enabled on the router at the same time? If not then it's an academic question as the client's address/subnet won't exist.

Yes, I occasionally use both the router's openvpn server and openvpn clients simultaneously. However, I also noticed that even with the vpn_client1 & 2 disabled, a remote client of vpn_server1 is still unable to reach the LAN (other than 192.168.0.1 - the router's LAN IP). As far as a solution, I have one: Do not specify a range of 10.8.0.0/24 for vpn_server1's subnet. But I would like to gain some understanding.

If this is in fact a conflict, then it kind of makes sense to me that choosing 10.8.0.0/24 for the vpn server subnet might not work as expected.
If that assertion is correct, I then do not understand why the router offers a default subnet of 10.8.0.0/24 for 1st vpn server whilst it configures addresses in the same range for the config for vpn_client1.

vpn_client1_remote=10.8.0.1
vpn_client1_local=10.8.0.2

As far as I know, these aren't exposed in the web UI so its not immediately obvious. Nor do I understand how those two vars are used in relation to the vpn_client.

Thanks for the help.

 

[ColinTaylor]

I just did a little test and when the router's VPN client was started the server side pushed the IP address and subnet to the client (10.12.0.x in my case). So I think in normal use those client values that you're looking at are probably just default values the router will use if the server doesn't push anything.

If you're getting a conflict of subnet ranges I suspect you need to look elsewhere. Have a look at System Log > Routing Table to see if the 10.8.x.x range is in use by something.

 

[keeka]

In networking, ip addresses are like phone numbers and part of it identifies the network and part of it identifies the host and therefore must be unique. You can't have two different people with the same mobile phone number can you? Ip addresses are the same.

Part of the addresses specified by rfc1918 are used as you would private extensions. Meaning like a private phone extension they are not publicly accessible. These addresses are used by multiple people for private use. But similar to private extensions, they can only be addressed uniquely when they don't overlap or they are translated to public addresses.

this is just some very basic information. If you really want to know more, study up on RFC1918.

Thanks! My networking knowledge is novice level. Still I hope I've grasped the network/host concept and private address ranges.

 

[keeka]

I just did a little test and when the router's VPN client was started the server side pushed the IP address and subnet to the client (10.12.0.x in my case). So I think in normal use those client values that you're looking at are probably just default values the router will use if the server doesn't push anything.

If you're getting a conflict of subnet ranges I suspect you need to look elsewhere. Have a look at System Log > Routing Table to see if the 10.8.x.x range is in use by something.

Hi Colin. Those two values, I am assuming from thier names, are involved in the router's own vpn_client process rather than the server.

 

[ColinTaylor]

Hi Colin. Those two values, I am assuming from thier names, are involved in the router's own vpn_client process rather than the server.

Like I said above, I don't believe those values are used by the router's VPN client (in normal usage). The VPN server pushes it's own values to the router.

Sep 16 18:49:22 openvpn[13076]: SENT CONTROL [vpnbook.com]: 'PUSH_REQUEST' (status=1)
Sep 16 18:49:22 openvpn[13076]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 213.186.33.99,dhcp-option DNS 91.239.100.100,route 10.12.0.1,topology net30,ping 5,ping-restart 30,ifconfig 10.12.0.66 10.12.0.65,peer-id 0,cipher AES-256-GCM'

In any case, if you don't have the VPN client active this won't be the cause.

 

[keeka]

Like I said above, I don't believe those values are used by the router's VPN client (in normal usage). The VPN server pushes it's own values to the router.

Sep 16 18:49:22 openvpn[13076]: SENT CONTROL [vpnbook.com]: 'PUSH_REQUEST' (status=1)
Sep 16 18:49:22 openvpn[13076]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 213.186.33.99,dhcp-option DNS 91.239.100.100,route 10.12.0.1,topology net30,ping 5,ping-restart 30,ifconfig 10.12.0.66 10.12.0.65,peer-id 0,cipher AES-256-GCM'

In any case, if you don't have the VPN client active this won't be the cause.

OK got it now. So, there would not be a conflict choosing 10.8.0.0/24 subnet for the router's vpn server. Unless that is the remote vpn server pushes an address to say, vpnclient1, that falls in that same range? Would that cause a conflict?

 

[john9527]

Like I said above, I don't believe those values are used by the router's VPN client (in normal usage).

@keeka
Those values are only used by the VPN client if you don't use TLS authentication, but switch to Static key. Then they are exposed in the gui.

 

[ColinTaylor]

Would that cause a conflict?

I would imagine so.

 

[john9527]

I would imagine so.

I'm pretty sure if that should happen, it will show up an 'Address Conflict' error on the VPN status page and the client (or server) will refuse to start. I remember that is one of the error classes that are posted.