My network scheme:

|localhost| tun1--> VPN <--tun0 |work station| wlan0--> |router| --> (

localhost: Arch Linux x86-64

work station: CentOS 6 x86-64

I want to connect directly from localhost to network, without SSH port forwardings and such. Work station has access to this network. Also, work station has static IP in VPN.

tracepath from work station to host in

$ tracepath
 1?: [LOCALHOST]     pmtu 1500
 1: (                         15.293ms 
 1: (                          2.119ms 
 2: (                          2.085ms pmtu 1409
 2:  no reply
 3: (                           15.655ms reached
     Resume: pmtu 1409 hops 3 back 3 is default gateway for work station:

$ ip route | grep default
default via dev wlan0

I tried just to add route on my localhost, but it failed:

# ip route add via
RTNETLINK answers: Network is unreachable

I guess, that's pretty naive to add route to remote network in such way. How can I do this correctly? Maybe, I should share route table on somehow?


I tried Marius suggestion

iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE

But it didn't change anything. iptables NAT tables now show this on workstation:

# iptables -t nat -L
target     prot opt source               destination         

target     prot opt source               destination         
MASQUERADE  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination


I'm able to connect to ports in network using SSH port

ssh -L 5432: [email protected]

After this forwarding I'm able to connect to via localhost:5432. So, what I really want is just option to connect directly to


I use openvpn to connect to VPN.

ip route on localhost:

$ ip route
default via dev wlp2s0 src metric 302 via dev tun1 via dev tun1 dev wlp2s0 proto kernel scope link src metric 302 via dev tun1 dev tun1 proto kernel scope link src via dev tun1 via dev tun1

ip route on workstation:

$ ip route via dev tun0 via dev tun0 dev tun0  proto kernel  scope link  src via dev tun0 dev wlan0  proto kernel  scope link  src via dev tun0 via dev tun0 
default via dev wlan0

nmap to one of interested ports in from localhost:

$ nmap -p5432

Starting Nmap 7.31 ( https://nmap.org ) at 2016-11-02 11:40 MSK
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.11 seconds

from workstation:

$ nmap -p5432

Starting Nmap 5.51 ( http://nmap.org ) at 2016-11-02 11:42 MSK
Nmap scan report for
Host is up (0.034s latency).
5432/tcp open  postgresql

Nmap done: 1 IP address (1 host up) scanned in 0.16 seconds
  • Please provide the output of ip route when connected to the VPN. Also, what VPN software are you using?
    – Daniel B
    Nov 2, 2016 at 8:34
  • @DanielB I use openvpn. Please, check edit 3 for ip route outputs. Nov 2, 2016 at 8:49
  • I see. That makes it clear why you can’t add a route. It would have to go through – your only direct peer on the OpenVPN connection. What is that? Your VPN server?
    – Daniel B
    Nov 2, 2016 at 9:07
  • @DanielB yes, is VPN server which I'm connecting to, and it doesn't know about needed for me network. Only workstation knows about it. I thought, there should be some way to manage route using Nov 2, 2016 at 9:23
  • When you add a route, you tell your PC about the next hop to the destination. The next hop has to be reachable directly. The next hop device will have the “next next” hop in its routing table and so on. That’s how IP routing works. One way to simplify things would be to switch your OpenVPN topology from p2p/net30 to subnet.
    – Daniel B
    Nov 2, 2016 at 9:35

1 Answer 1


Connecting directly mean that you want to use layer3 routing. Routing works pretty simple: packets enter the router and exit to the direction determined from the destination address (in the normal routing at least). Then enter the next router and the same process repeated, until the packet reaches the destination (or hits the wall by not being able to reach).

This requires that in forward direction all routers towards 10.128/16 should have a route of 10.128/16 to somewehere (preferably to the next router in the chain). It also requires that all routers in the backpath have a route for (preferably backwards direction) to make it possible for the reply to reach your machine.

Unless you do that properly on all routers in the path (vpn and router) it will not work.

(In the case where you are not administering the middle hops you can use a simple GRE tunnel between localhost and targets: it uses ~42 bytes of overhead on every package but relatively simple to setup, provided you have "intelligent" hosts on both ends.)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .