Add route to remote network

Question

My network scheme:

|localhost| tun1--> VPN <--tun0 |work station| wlan0--> |router| --> (10.128.0.0/16)

localhost: Arch Linux x86-64

work station: CentOS 6 x86-64

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

tracepath from work station to host in 10.128.0.0/16:

$ tracepath 10.128.29.59
 1?: [LOCALHOST]     pmtu 1500
 1:  192.168.225.1 (192.168.225.1)                         15.293ms 
 1:  192.168.225.1 (192.168.225.1)                          2.119ms 
 2:  192.168.225.1 (192.168.225.1)                          2.085ms pmtu 1409
 2:  no reply
 3:  10.128.29.59 (10.128.29.59)                           15.655ms reached
     Resume: pmtu 1409 hops 3 back 3

192.168.255.1 is default gateway for work station:

$ ip route | grep default
default via 192.168.225.1 dev wlan0

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

# ip route add 10.128.0.0/16 via 10.255.255.252
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 10.255.255.252 somehow?

EDIT 1:

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
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

EDIT 2:

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

ssh -L 5432:10.128.29.59:5432 [email protected]

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

EDIT 3:

I use openvpn to connect to VPN.

ip route on localhost:

$ ip route
default via 192.168.1.1 dev wlp2s0 src 192.168.1.253 metric 302 
10.0.0.0/16 via 192.168.193.29 dev tun1 
10.255.0.0/16 via 192.168.193.29 dev tun1 
192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.253 metric 302 
192.168.193.0/24 via 192.168.193.29 dev tun1 
192.168.193.29 dev tun1 proto kernel scope link src 192.168.193.30 
193.26.135.101 via 192.168.193.29 dev tun1 
213.24.160.78 via 192.168.193.29 dev tun1

ip route on workstation:

$ ip route
193.26.135.101 via 10.255.255.251 dev tun0 
213.24.160.78 via 10.255.255.251 dev tun0 
10.255.255.251 dev tun0  proto kernel  scope link  src 10.255.255.252 
192.168.193.0/24 via 10.255.255.251 dev tun0 
192.168.225.0/24 dev wlan0  proto kernel  scope link  src 192.168.225.165 
10.0.0.0/16 via 10.255.255.251 dev tun0 
10.255.0.0/16 via 10.255.255.251 dev tun0 
default via 192.168.225.1 dev wlan0

nmap to one of interested ports in 10.128.0.0/16 from localhost:

$ nmap -p5432 10.128.29.59/32

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 10.128.29.59/32

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

Nmap done: 1 IP address (1 host up) scanned in 0.16 seconds

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 192.168.1.0/24 (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.)