Return to Answer

(2) ways you can connect to a Pi on an RFC 1918 address:

• VPN
• DNAT

Neither involves configuration on the Pi itself, but the router in front of it. This topic is really one of general networking than the Pi itself, so I'll give you a high-level overview of what's involved:

So your connection looks like:

ssh [email protected] -p 21

Configuration: Ask your ISP for a block of Public IPs. If you ask for a /29, you're more likely to get your request approved than if you ask for a /28 (or greater). Configure one of these available addresses ( excluding the use of the router's IP of course) on the router and setup a DNAT rule in the router's forwarding table to forward traffic from the public IP to the internal IP. The interface (CLI/webGUI) for accomplishing these tasks will vary between router manufacturers.

So your connection looks like:

ssh [email protected] -p 21

Compare this to the VPN example above which uses the LOCAL IP

Less complex to setup than an IPsec VPN. Still requires a bit of networking knowledge, but again, a great opportunity for gaining those skills.

Firewall

Finally, ensure the FW allows traffic to the Pi on the forward table. Even if your VPN or DNAT is setup correctly, if you haven't allowed thee traffic you'll be scratching your head wondering why it's you can't connect ;-)

Short Answer:

Here's a TESTED and WORKING specimen config from my MikroTik router that you can use as a model for your own router.

chain=dstnat action=dst-nat to-addresses=192.168.0.6 to-ports=21 protocol=tcp in-interface=ether1-Gateway dst-port=60000 log=no log-prefix=""

Where:

• "ether1-Gateway" is my connection to Internet
• "dst-port=60000" is an arbitrary port chosen from the "Dynamic/Private" port range.
• "to-addresses=192.168.0.6" The Pi
• "to-ports=21" The port on Pi receiving the forwarded traffic

WARNING: Avoid "Privileged" port numbers such as "21"- use a high port in the "Dynamic/Private" port range. "21" is used for FTP and now some routers are offering FTP services...

So when I SSH into the router on port 60000 as follows:

ssh [email protected] -p 60000 

The router sends my traffic to the FORWARDED port "21":

192.168.0.6 on port 21

DON'T FORGET TO CHECK YOUR FIREWALL RULES allow the desired connectivity

Long Answer:

Using DNAT to connect remote-in to internal hosts that are NOT offering public services such as mail or web servers is not ideal. Using a VPN to connect to hosts on Local IPs is.

Here's a comparison between the (2) methods to connect remotely to a host on an RFC 1918 address:

So once your VPN connection is established to your home/work router, your SSH connection looks like this:

ssh [email protected] -p 60000

Note that you're reaching it on a LOCAL IP.

In the "Short Answer" I showed you a very simple way to do a DNAT using the ROUTER's own Public IP. The following method is a bit more elegant, where each host has traffic forwarded on a Public IP dedicated to it.

Configuration: A Better DNAT Solution:

Ask your ISP for a block of Public IPs. If you ask for a /29, you're more likely to get your request approved than if you ask for a /28 (or greater). Configure these Public IP addresses on the router and setup a DNAT rule to forward traffic from the public IP to the internal IP. Each host can have use a different public IP to forward traffic to it. Tidy.

Less complex to setup a DNAT than an IPsec VPN.

(2) ways you can connect to a Pi on an RFC 1918 address:

• VPN
• DNAT

Neither involves configuration on the Pi itself, but the router in front of it. This topic is really one of general networking than the Pi itself, so I'll give you a high-level overview of what's involved:

Using SSH:

I'm inferring that the user knows how to use SSH and that it's connecting to their Pi on an RFC 1918 non world-routable address is the problem they are trying to solve.

VPN: Preferred Method

Configuration: You'll need to configure VPN on the router, then configure a client on your computer/device to establish a VPN connection to the router.

So your connection looks like:

ssh [email protected] -p 21

Upside:

• Using a VPN, you don't publicly expose your Pi. You can talk directly to it on the local address once you establish the VPN connection to your router.

Downside:

• Configuring an IPsec VPN on the router requires a little bit of networking knowledge. From the nature of your question, I suspect you don't possess the fundamental skills to do this easily. But hey- great opportunity to learn!

• Some countries are not VPN friendly and do not want you passing traffic through an encrypted tunnel...

DNAT

Configuration: Ask your ISP for a block of Public IPs. If you ask for a /29, you're more likely to get your request approved than if you ask for a /28 (or greater). Configure one of these available addresses ( excluding the use of the router's IP of course) on the router and setup a DNAT rule in the router's forwarding table to forward traffic from the public IP to the internal IP. The interface (CLI/webGUI) for accomplishing these tasks will vary between router manufacturers.

So your connection looks like:

ssh [email protected] -p 21

Compare this to the VPN example above which uses the LOCAL IP

Upside:

Less complex to setup than an IPsec VPN. Still requires a bit of networking knowledge, but again, a great opportunity for gaining those skills.

Downside:

• Just as you can connect to your Pi from the outside world, so can anybody else: traffic is being forwarded from the Public IP that is being mapped by the DNAT rule to the Pi's internal (non world-routable) local IP.

• Requires your ISP to assign you a block of Public IPv4 IPs, which are getting scarcer and scarcer by the day. And it's very likely they'll charge you a monthly fee for the block they assign to you so potentially a recurring cost to this solution (thanks @goldilocks)

• You'll lose your current Public IP the router is using, which may or may not be a problem. If they assign you the block of Public IPs, the router's address itself must be from within this range of IPs.

• If you change ISPs, you will lose this block of Public IPs and your connectivity to the Pi will be busted. The ISP owns the block- they are letting you use their IPs only.

(2) ways you can connect to a Pi on an RFC 1918 address:

• VPN
• DNAT

Neither involves configuration on the Pi itself, but the router in front of it. This topic is really one of general networking than the Pi itself, so I'll give you a high-level overview of what's involved:

VPN: Preferred Method

Configuration: You'll need to configure VPN on the router, then configure a client on your computer/device to establish a VPN connection to the router.

So your connection looks like:

ssh [email protected] -p 21

Upside:

• Using a VPN, you don't publicly expose your Pi. You can talk directly to it on the local address once you establish the VPN connection to your router.

Downside:

• Configuring an IPsec VPN on the router requires a little bit of networking knowledge. From the nature of your question, I suspect you don't possess the fundamental skills to do this easily. But hey- great opportunity to learn!

• Some countries are not VPN friendly and do not want you passing traffic through an encrypted tunnel...

DNAT

Configuration: Ask your ISP for a block of Public IPs. If you ask for a /29, you're more likely to get your request approved than if you ask for a /28 (or greater). Configure one of these available addresses ( excluding the use of the router's IP of course) on the router and setup a DNAT rule in the router's forwarding table to forward traffic from the public IP to the internal IP. The interface (CLI/webGUI) for accomplishing these tasks will vary between router manufacturers.

So your connection looks like:

ssh [email protected] -p 21

Compare this to the VPN example above which uses the LOCAL IP

Upside:

Less complex to setup than an IPsec VPN. Still requires a bit of networking knowledge, but again, a great opportunity for gaining those skills.

Downside:

• Just as you can connect to your Pi from the outside world, so can anybody else: traffic is being forwarded from the Public IP that is being mapped by the DNAT rule to the Pi's internal (non world-routable) local IP.

• Requires your ISP to assign you a block of Public IPv4 IPs, which are getting scarcer and scarcer by the day. And it's very likely they'll charge you a monthly fee for the block they assign to you so potentially a recurring cost to this solution (thanks @goldilocks)

• You'll lose your current Public IP the router is using, which may or may not be a problem. If they assign you the block of Public IPs, the router's address itself must be from within this range of IPs.

• If you change ISPs, you will lose this block of Public IPs and your connectivity to the Pi will be busted. The ISP owns the block- they are letting you use their IPs only.

Firewall

Finally, ensure the FW allows traffic to the Pi on the forward table. Even if your VPN or DNAT is setup correctly, if you haven't allowed thee traffic you'll be scratching your head wondering why it's you can't connect ;-)

(2) ways you can connect to a Pi on an RFC 1918 address:

• VPN
• DNAT

Neither involves configuration on the Pi itself, but the router in front of it. This topic is really one of general networking than the Pi itself, so I'll give you a high-level overview of what's involved:

Using SSH:

I'm inferring that the user knows how to use SSH and that it's connecting to their Pi on an RFC 1918 non world-routable address is the problem they are trying to solve.

VPN: Preferred Method

Configuration: You'll need to configure VPN on the router, then configure a client on your computer/device to establish a VPN connection to the router.

Upside:

• Using a VPN, you don't publicly expose your Pi. You can talk directly to it on the local address once you establish the VPN connection to your router.

Downside:

• Configuring an IPsec VPN on the router requires a little bit of networking knowledge. From the nature of your question, I suspect you don't possess the fundamental skills to do this easily. But hey- great opportunity to learn!

• Some countries are not VPN friendly and do not want you passing traffic through an encrypted tunnel...

DNAT

Configuration: Ask your ISP for a block of Public IPs. If you ask for a /29, you're more likely to get your request approved than if you ask for a /28 (or greater). Configure one of these available addresses ( excluding the use of the router's IP of course) on the router and setup a DNAT rule in the router's forwarding table to forward traffic from the public IP to the internal IP. The interface (CLI/webGUI) for accomplishing these tasks will vary between router manufacturers.

Upside:

Less complex to setup than an IPsec VPN. Still requires a bit of networking knowledge, but again, a great opportunity for gaining those skills.

Downside:

• Just as you can connect to your Pi from the outside world, so can anybody else: traffic is being forwarded from the Public IP that is being mapped by the DNAT rule to the Pi's internal (non world-routable) local IP.

• Requires your ISP to assign you a block of Public IPv4 IPs, which are getting scarcer and scarcer by the day. And it's very likely they'll charge you a monthly fee for the block they assign to you so potentially a recurring cost to this solution (thanks @goldilocks)

• You'll lose your current Public IP the router is using, which may or may not be a problem. If they assign you the block of Public IPs, the router's address itself must be from within this range of IPs.

• If you change ISPs, you will lose this block of Public IPs and your connectivity to the Pi will be busted. The ISP owns the block- they are letting you use their IPs only.

(2) ways you can connect to a Pi on an RFC 1918 address:

• VPN
• DNAT

Neither involves configuration on the Pi itself, but the router in front of it. This topic is really one of general networking than the Pi itself, so I'll give you a high-level overview of what's involved:

Using SSH:

I'm inferring that the user knows how to use SSH and that it's connecting to their Pi on an RFC 1918 non world-routable address is the problem they are trying to solve.

VPN: Preferred Method

Configuration: You'll need to configure VPN on the router, then configure a client on your computer/device to establish a VPN connection to the router.

So your connection looks like:

ssh [email protected] -p 21

Upside:

• Using a VPN, you don't publicly expose your Pi. You can talk directly to it on the local address once you establish the VPN connection to your router.

Downside:

• Configuring an IPsec VPN on the router requires a little bit of networking knowledge. From the nature of your question, I suspect you don't possess the fundamental skills to do this easily. But hey- great opportunity to learn!

• Some countries are not VPN friendly and do not want you passing traffic through an encrypted tunnel...

DNAT

Configuration: Ask your ISP for a block of Public IPs. If you ask for a /29, you're more likely to get your request approved than if you ask for a /28 (or greater). Configure one of these available addresses ( excluding the use of the router's IP of course) on the router and setup a DNAT rule in the router's forwarding table to forward traffic from the public IP to the internal IP. The interface (CLI/webGUI) for accomplishing these tasks will vary between router manufacturers.

So your connection looks like:

ssh [email protected] -p 21

Compare this to the VPN example above which uses the LOCAL IP

Upside:

Less complex to setup than an IPsec VPN. Still requires a bit of networking knowledge, but again, a great opportunity for gaining those skills.

Downside:

• Just as you can connect to your Pi from the outside world, so can anybody else: traffic is being forwarded from the Public IP that is being mapped by the DNAT rule to the Pi's internal (non world-routable) local IP.

• Requires your ISP to assign you a block of Public IPv4 IPs, which are getting scarcer and scarcer by the day. And it's very likely they'll charge you a monthly fee for the block they assign to you so potentially a recurring cost to this solution (thanks @goldilocks)

• You'll lose your current Public IP the router is using, which may or may not be a problem. If they assign you the block of Public IPs, the router's address itself must be from within this range of IPs.

• If you change ISPs, you will lose this block of Public IPs and your connectivity to the Pi will be busted. The ISP owns the block- they are letting you use their IPs only.