OpenVPN Support Forum

Greetings,

I am trying to optimize my home setup. I registered an account to ask this question; if it is not appropriate for this sub(forum), please kindly let me know.

I run an OpenVPN server at my router so I can get access to my private network while away (or from work):

all devices at home are on the 192.168.1.* subnet
my router/OpenVPN server is configured to handout 10.8.0.* address when connected.

One of my device at home is a NAS server (192.168.1.250) which runs an OpenVPN client and connects to an external OpenVPN server (slickvpn). On my NAS, I have several daemons running, all of which have access via web interface.

When my NAS is connected to the external OpenVPN server (slickvpn), I cannot access these web interfaces even through I am on the 10.8.0.* subnet. However, I can access these web interfaces if I am on the 192.168.1.* subnet. ssh into the NAS server while on 10.8.0.* subnet is also not possible.

When the NAS is NOT connected to an external OpenVPN server, I can access these web interfaces regardless if I am on the 10.8.0.*/192.168.1.* subnet. I can also ssh into the NAS.

Question: Is there a way to access the NAS while the NAS is connected to an external OpenVPN server while I am (say, at work) connected to my home network through my own OpenVPN server running on my router?

I apologize in advance if these are trivial questions. I am learning OpenVPN as we speak,

regards,

Please see:
https://community.openvpn.net/openvpn/w ... versubnet.

For further help please see:
viewtopic.php?f=30&t=22603#p68963

Adding to the "external" VPN client conf on the NAS should make it work. (I'm not entirely sure if it would still be okay if the external VPN also assigns the its clients 10.8.0.0/24 addresses though.

Another approach would be to "masquerade" packets from your own VPN clients to 192.168.1.250 as from the your VPN server, as apparently packets from the NAS to 192.168.1.0/24 are not routed into the tunnel to the external VPN (block-local not in use for redirect-gateway I suppose).

Either of these should avoid the replies for 10.8.0.0/24 from being routed into the tunnel to the external VPN.