0

I have 2 hosts (linux) on my home LAN. Host A makes an SSH connection to the host B. Now, when I connect A to a VPN, I am still able to work with the SSH terminal from A to B. As a simple proof, I checked the public ip from the SSH conn to B with curl, and it is different from the A's ip (that is inside the VPN now)

Is this expected? Is it a bug? As I understand, connecting to the VPN should kill the SSH connection from A to B as A 'should not be visible' in the LAN anymore. Right?

2
  • 1
    Not right. Kernel decides where to route when establishing a connection. If you bring up a new device, it doesn't affect the already established connections. – Ipor Sircer Jul 9 '18 at 20:15
  • #IporSirce - That is simply false. Connection tracking is done in the kernel, but this does not affect routing of packets - it affects NAT and rewriting of packet headers. Packets are routed based on source,destination, port and flags in the packet at thetome the packet is generated - indeed it is that functionality which makes the Internet able to route arround damage. – davidgo Jul 9 '18 at 20:41
1

This is working as expected.

The path that a packet takes is determined by the route table. In the typical case -

  • The netmask for the route defines a group of IP addresses reachable over a given interface.
  • A VPN typically defines a new route and/or default route to supercede the pre-existing route, and still requires the specific routes associated with reaching the router. This means the route for systems in the same subnet (which in Soho networks is usually the same as the LAN) remain.
  • Because packets to other machines in the LAN are routed out the interface associated with the subnet, traffic on the LAN does not traverse the VPN.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.