[SOLVED] OpenVPN access other subnets

Aug 19, 2019
6
1
15
Hi,

Im have setup an OpenVPN server/client solution for a customer but ran into problems when trying to connect to subnets other than the vpn subnet.

Main subnet is 192.168.100.0 where the firewall is and the OpenVPN server

Other subnets are:
192.168.101.0
192.168.102.0

VPN subnet:
10.10.10.0

Client subnet
192.168.50.0

I can connect from the client subnets and get assigned to 10.10.10.0 but there is no route to access the other subnets.

In the Server.ovpn config

push route is set to 192.168.100.0
route is set to include clients subnet 192.168.50.0

In the clientVPN

Ifconfig-push set to 10.10.10. range
iroute is set to client subnet 192.168.50.0

What am I doing wrong ?
 
Solution
Actually the 192.168.50.0 network is just for testing at the moment.

There will be more client subnets added involving 3rd party companies that need to access all 3 subnets in Building A.
Some external engineers would also need to work from home etc.
Building to building I would have an IPSec tunnel setup with AES Algroithm, 256bit key lenght, SHA512 Hash, and DH Group 18 (8192bit) or 30 (brainpool ecp512). For the other OpenVPN stuff here is a link to their how-to https://openvpn.net/community-resources/how-to/#policy
Hi,

Im have setup an OpenVPN server/client solution for a customer but ran into problems when trying to connect to subnets other than the vpn subnet.

Main subnet is 192.168.100.0 where the firewall is and the OpenVPN server

Other subnets are:
192.168.101.0
192.168.102.0

VPN subnet:
10.10.10.0

Client subnet
192.168.50.0

I can connect from the client subnets and get assigned to 10.10.10.0 but there is no route to access the other subnets.

In the Server.ovpn config

push route is set to 192.168.100.0
route is set to include clients subnet 192.168.50.0

In the clientVPN

Ifconfig-push set to 10.10.10. range
iroute is set to client subnet 192.168.50.0

What am I doing wrong ?
I haven't setup OpenVPN that way, we use it via pfsense, but I think you need to add the additional subnets to the Server.ovpn configuration.

It would look like this:
push route is set to 192.168.100.0
route is set to include clients subnet 192.168.50.0, 192.168.101.0, 192.168.102.0

Basically since the extra subnets aren't in the configuration file, they won't be able to be accessed.
 
Aug 19, 2019
6
1
15
Thanks for the quick reply.

Building A has 3 floors with 3 separate subnets:

Main subnet 192.168.100.0 where both the FW and the OpenVPN srv is running.
Same building also has subnets 192.168.101.0 and 192.168.102.0

Building B is the remote site from where the clients on 192.168.50.0 network will connect to Building A´s all 3 subnets.

I added all the subnets in server config but still the same.

Im not able to reach a device on the 192.168.100.0
 
Thanks for the quick reply.

Building A has 3 floors with 3 separate subnets:

Main subnet 192.168.100.0 where both the FW and the OpenVPN srv is running.
Same building also has subnets 192.168.101.0 and 192.168.102.0

Building B is the remote site from where the clients on 192.168.50.0 network will connect to Building A´s all 3 subnets.

I added all the subnets in server config but still the same.

Im not able to reach a device on the 192.168.100.0
Do all people on the 192.168.50.0 network need to connect to those subnets? If so use an IPSec tunnel instead of individual VPNs.
 
Aug 19, 2019
6
1
15
Actually the 192.168.50.0 network is just for testing at the moment.

There will be more client subnets added involving 3rd party companies that need to access all 3 subnets in Building A.
Some external engineers would also need to work from home etc.
 
Actually the 192.168.50.0 network is just for testing at the moment.

There will be more client subnets added involving 3rd party companies that need to access all 3 subnets in Building A.
Some external engineers would also need to work from home etc.
Building to building I would have an IPSec tunnel setup with AES Algroithm, 256bit key lenght, SHA512 Hash, and DH Group 18 (8192bit) or 30 (brainpool ecp512). For the other OpenVPN stuff here is a link to their how-to https://openvpn.net/community-resources/how-to/#policy
 
Solution
Aug 19, 2019
6
1
15
I think it´s working now. I forgot that the stand alone Vpn server considered itself as a router. I solved it in the firewall by adding a static route to the VPN subnet with the Vpn server as next hop.

Thanks for your input :)
 
  • Like
Reactions: jeremyj_83
Glad you got it working. I've only worked with IPsec vpn routers, but in those devices, I would have had to create 3 different tunnels, one for each address space.
With IPSec you have the P1 connection, which is from public IP to public IP, and then the P2's under that which allows for the different private IP subnets. Each end point on the IPSec tunnel needs to be setup the say way. If your P2 list is out of order on both ends it will not go any further than the only good connections.

EX:
Endpoint1Endpoint2
P1 - Endpoint1 PubIP to Endpoint2 PubIPP1 - Endpoint2 PubIP to Endpoint1 PubIP
P2 - 192.168.100.0/24 to 192.168.50.0/24P2 - 192.168.50.0/24 to 192.168.100.0/24
P2 - 192.168.102.0/24 to 192.168.50.0/24P2 - 192.168.50.0/24 to 192.168.101.0/24
P2 - 192.168.101.0/24 to 192.168.50.0/24P2 - 192.168.50.0/24 to 192.168.102.0/24
In this example only the first P2 will connect as the entries line up. The other 2 will not connect since it stops one it gets to a failed connection. I know this because when I rebuilt my IPSec tunnels not all the P2s were lined up perfectly. I had to go through and remove all the ones that didn't line up and redo it. That is a pain with 36 P2s.
 
And I though getting cisco and juniper routers were complex. It is actually somewhat trivial it seems compare to this. Used to create the IPSEC tunnel establish OSPF over it and all the local subnets on both sides just "magically" migrate to the other side because of OSPF. The hard part I always though was all the IPSEC parms that had to match not the routing.
 
And I though getting cisco and juniper routers were complex. It is actually somewhat trivial it seems compare to this. Used to create the IPSEC tunnel establish OSPF over it and all the local subnets on both sides just "magically" migrate to the other side because of OSPF. The hard part I always though was all the IPSEC parms that had to match not the routing.
Well I should say this is with pfSense so I'm sure other companies would be different. However, as an admin I personally wouldn't want the connections to magically appear as you might not want everyone to have access to certain subnets.
 
Well I should say this is with pfSense so I'm sure other companies would be different. However, as an admin I personally wouldn't want the connections to magically appear as you might not want everyone to have access to certain subnets.
Don't take things so serious. You actually have to configure the router to inject local subnets and you can easily filter any you do not want ether before they are distributed into the OSPF area or before they are injected into the router table. I used to have hundreds of small offices that we had connected. It would be a nightmare to have to log into every router in every location every time a office was turned up or down and make configuration changes. It was so nice that OSPF just handled issues like that for me.
 
  • Like
Reactions: jeremyj_83