How to remote access a raspberry pi connected to a VPN?

1

I have a Pi thats always on and connected to a VPN, which means I cannot access it remotely. I am trying to find a solution to access it remotely, so I am seeking advice from the gurus here.

My preferred/easiest solution so far is to use my 2nd Pi, soon arriving and to be used for remote monitoring. I am thinking of mounting a shared drive from the 1st on to that one, and ssh-ing into it, as it won't be connected to a VPN.

That is still a bit convoluted though. Any other options available? Any comments/ideas more than welcome.

Thanks

user20224

Posted 2015-10-03T17:43:37.500

Reputation: 49

1Pls see the edit to my post, for an explanation of what I meant succintly in my comment. – MariusMatutiae – 2015-10-04T09:18:47.783

A-w-e-s-o-m-e. I'm going to study all that – user20224 – 2015-10-04T15:30:32.740

Answers

1

Are you in the same LAN as your first RPI? If so, you should not have lost contact with it at all. VPNs work by adding routes, not by suppressing existing ones. So, if you had a route like 

    192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.74  metric 1

before starting up the VPN, then the same route must continue to exist after the VPN modifies your routing table. This leaves your RPI accessible from your LAN. It is possible you have to contact it by IP address rather than by name (unless of course you use a local DNS); it is also possible that from the RPI you cannot access other pcs in your LAN via name, because DNS has been rerouted thru the VPN (not necessarily so, but most frequent).

If the RPI is not inyour LAN, then it is a different matter,; pls specify whether this is the case.

EDIT:

You have three possibilities, two easy ones and a slightly more complex one.

  1. If you always connect from, say, 1.2.3.4, just add a suitable route to the first RPI's routing table:

     ip route add 1.2.3.4./32  via 192.168.0.1 dev eth0

This will route packets for 1.2.3.4 thru the regular LAN gateway (I assumed it is 192.168.0.1, if not modify accordingly), bypassing the VPN altogether;

  1. Since you are using a commercial VPN this trick is unlikely to work. If you had a VPN server on your own VPS (which, BTW, is what I always do, cheap VPSes are 3 dollars/euros a month, and some have unmetered connections), then you simply connect to the VPN server via the VPN, then contact your RPI by means of ssh, using as its IP address that of its tunnel end! So, if your VPN tunnel has addresses 10.0.0.1 for the server and, say 10.0.0.6 for the RPI client, this

       ssh me@10.0.0.6

would connect you to the RPI. Since you are using a commercial provider of VPN, even if you can connect to their server via VPN with the pc which is not the RPI, I doubt they would allow you to contact another client: it would be a lttle like letting the fox into the hen pen, wouldn't it?

  1. The more complex solution is explained here for the first RPI: the basic idea is to setup a second routing table, something that can be done only on Linux, not even on Unix; this second routing table does not use the VPN, just your normal LAN gateway. To identify the packets to be routed via this second routing table, you will have to mark all packets with a certain characteristic, for instance those entering the RPI on port 22 (ssh's port) with the CONNTRACK module, not the MARK module: this marks the whole connection, not just the individual packet, including the ESTABLISHED, RELATED packets. Now you can setup an ip rule that selects the marked packets telling the kernel to use the second routing table, i.e. the one without VPN.

MariusMatutiae

Posted 2015-10-03T17:43:37.500

Reputation: 41 321

Thanks for the answer. The RPI is in my LAN, and I want to access from outside my LAN. As it is connected to a VPN, that makes it impossible to access it from outside my LAN. About my solution: When I meant to ssh into the 2nd, I meant ssh-ing from outside my LAN as well (and since both PIs will be in my LAN, they can access each other). So my "solution" is to use an intermediary accessible point (the 2nd RPI) to get to my otherwise inaccessible data (1st RPI). – user20224 – 2015-10-03T19:06:15.197

1@user20224 This will surely work,because your first RPI will see the connection coming from within the LAN, and it has the proper route to respond. You can easily connect directly to your fist RPI from outside your LAN if 1 you try to connect to it always from the same IP address (or a small number thereof), or 2 you may access the VPN server also with the pc from which you are trying to connect to the first RPI. It is possible to connect to the RPI directly also in the general case, but it requires some more work. Let me know whether any of this interests you. – MariusMatutiae – 2015-10-03T21:01:37.230

Yes sure, I'm really curious about your ideas, as I have no clue on how to do any of what you suggest. To clarify, the VPN server is a 3rd party service to anonymize traffic, and I have no control and access to it. – user20224 – 2015-10-04T04:24:37.507

0

I had a similar problem, however it was less generic. I was using NordVPN's Linux installation on a headless Raspberry Pi running Raspbian Buster. It would connect fine and any SSH connection that was up would persist however the Pi would not respond to pings or new SSH connections from the local network.

Running nordvpn whitelist add subnet 192.168.0.0/1 solved the issue. (Assuming your local network is 192.168.x.x)

Unlike its device apps, the cmd-line NordVPN blocks local networking by default.

If you also had this issue you can go here, scroll down to the email link and let the NordVPN team know.

Harvs

Posted 2015-10-03T17:43:37.500

Reputation: 1

0

If you mean that the VPN makes your Pi inacessible to the local network (I assume this, since otherwise the VPN should provide SSH access) and you can't access it even if connected to the same router, you can use virtual interfaces to do that.

For example, if you have an eth0 interface, you may create a new virtual interface like this:

ifconfig eth0:0 123.123.22.22

Then, usual Linux methods for interface configuration should apply. More info.

Ronan Paixão

Posted 2015-10-03T17:43:37.500

Reputation: 131

Asked: 2015-10-03T17:43:37.500

Viewed: 3 520 times

Active: 2020-02-17T17:06:54.147