Cannot Access server remotely through VPN tunnel when server is connected to am openVPN service

Question

I created a VPN tunnel to my home LAN. The VPN Tunnel is successful because I can access my router's gateway.

I have ssh access to one of the servers on the network (192.168.1.113). I Tested this connection locally and it works. But, the server itself is using a VPN so its public IP address differs from the LAN's public IP.

The Issue is that I cannot ssh into 192.168.1.113 remotely with the VPN Tunnel switched on. Pinging the server results in:

PING 192.168.1.113 (192.168.1.113): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
--- 192.168.1.113 ping statistics ---
135 packets transmitted, 0 packets received, 100.0% packet loss

As a test, I switched off the VPN on 192.168.1.113 and it works. I can connect remotely with VPN tunnel. But why is this happening? If I tunnel to my LAN that should mean I am another device on my LAN. No different than being physically there right?

Some Details

• Router: Archer C7 with OpenVPN Server
• 192.168.1.113 using openVPN with a protonVPN configuration file

Update

When access the router gateway remotely from tunnel, My remote pc is not visible under LAN network devices. But it is visible under VPN Connections with this info:

• Remote IP: 84.185.102.210
• Assigned IP: 10.8.0.6
• The assigned IP is part of the openVPN subnet/netmask: 10.8.0.0/24

Update 2

Looking at tcpdump with sudo tcpdump -eni any icmp while pinging 192.168.1.113 from vpn tunnel is showing:

12:29:21.027220 eth0  In  ifindex 2 e8:48:b8:e1:57:1a ethertype IPv4 (0x0800), length 104: 10.8.0.6 > 192.168.1.113: ICMP echo request, id 45097, seq 32, length 64
12:29:21.027357 tun0  Out ifindex 1063 ethertype IPv4 (0x0800), length 104: 192.168.1.113 > 10.8.0.6: ICMP echo reply, id 45097, seq 32, length 64
12:29:22.004265 eth0  In  ifindex 2 e8:48:b8:e1:57:1a ethertype IPv4 (0x0800), length 104: 10.8.0.6 > 192.168.1.113: ICMP echo request, id 45097, seq 33, length 64
12:29:22.004411 tun0  Out ifindex 1063 ethertype IPv4 (0x0800), length 104: 192.168.1.113 > 10.8.0.6: ICMP echo reply, id 45097, seq 33, length 64

Update 3

using arp -a on Mac machine to check other devices on a network, does not show any other devices when I am on the tunnel. Trying the same command when directly on LAN shows the Server I want to connect to.

Answer 1

But why is this happening? If I tunnel to my LAN that should mean I am another device on my LAN. No different than being physically there right?

You're not exactly on your LAN. The VPN is a separate subnet which is interconnected with your LAN, but nevertheless a "distant" network from the server's point of view.

The server always has a local route for 192.168.1.0/24 (the network it is directly in), but most likely does not have one for 10.8.0.0/24 – it relies on the default route to reach that (as it still leads through the same router either way).

When the server is connected to the VPN, however, its primary default route is no longer through the Archer but through the VPN instead. So whenever the server receives a packet from 10.8.0.6, it tries to respond through the VPN (which discards the packet at some point). You can see in tcpdump that the "ICMP Echo Reply" packets are being sent, but they're being sent through the "tun0" device instead of Ethernet.

Basic IP routing is per-packet, not per-connection, and responses are not automatically routed the same way that the initial packet came from – the server routes its outbound packets independently of any inbound packet that prompted them. (In other words, routing can be asymmetric.)

In your case, the simplest way to avoid this is to define a specific route for 10.8.0.0/24 on the server, so that packets to this destination will always go through the Archer even if the VPN is up. (More-specific routes always have priority over less-specific ones; you don't need to set specific metrics or anything.)

In more complex setups (e.g. if the client address was unpredictable and not limited to just the VPN /24) you could use iptables or nftables rules to apply a "mark" to inbound connections and have ip rule choose one of several default routes depending on whether the outbound packet belongs to a connection marked as local or not.