Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

So far I have successfully created a virtual link between server A and server B using an unencrypted openvpn tunnel. I am trying to route some of server B's traffic through server A. Server B has 5 external IPs and I would like to add 5 local vpn IPs that redirect traffic to 5 IPs at server A, which would give server B 10 distinct outgoing IPs to the world. Obviously some routing needs to be done on both servers but I'm not getting anywhere after a day of googling and reading.

I did

ip route add default via 10.0.0.2 dev tun0 table vpn_table
ip rule add from 10.0.0.1/32 table vpn_table
ip rule add to 10.0.0.2/32 table vpn_table
ip route flush cache

on server B, and the same on server A but with IPs swapped. However, on server B when I do wget --bind-address=10.0.0.1 somewebsite it's not working, I guess because server A doesn't know what to do with the request.

Could anyone point me in the right direction?

EDIT

Someone suggested that server A doesn't need ip rules, so the situation I have right now is:

  1. setup openvpn link
  2. on server B I do the four ip command mentioned above

I think I'm still missing some routing info on server A. This is what tcpdump on server A outputs when I do wget --bind-address=10.0.0.1 http://www.cnn.com on server B:

tcpdump: WARNING: arptype 65534 not supported by libpcap - falling back to cooked socket
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
07:11:58.787908 IP 10.0.0.1.42802 > 157.166.248.10.80: S 2416144580:2416144580(0) win 14600 <mss 1410,sackOK,timestamp 858359606 0,nop,wscale 7>
07:11:59.786129 IP 10.0.0.1.42802 > 157.166.248.10.80: S 2416144580:2416144580(0) win 14600 <mss 1410,sackOK,timestamp 858359856 0,nop,wscale 7>
07:12:01.788535 IP 10.0.0.2 > 10.0.0.1: ICMP host 157.166.248.10 unreachable, length 68
07:12:01.788545 IP 10.0.0.2 > 10.0.0.1: ICMP host 157.166.248.10 unreachable, length 68

Wget on Server B says

Connecting to www.cnn.com (www.cnn.com)|157.166.248.11|:80... failed: No route to host.

EDIT 5/19/2014

Added SNAT on server A, right now tcpdump on server A is giving me (93.184.216.119 = www.example.com, 1.2.3.4 = server A's external IP that is now the source of packets coming from 10.0.0.1)

09:29:44.114475 IP 10.0.0.1.54691 > 93.184.216.119.80: S 717252699:717252699(0) win 14600 <mss 1410,sackOK,timestamp 903625938 0,nop,wscale 7>
09:29:45.113546 IP 10.0.0.1.54691 > 93.184.216.119.80: S 717252699:717252699(0) win 14600 <mss 1410,sackOK,timestamp 903626188 0,nop,wscale 7>
09:29:47.116587 IP 1.2.3.4 > 10.0.0.1: ICMP host 93.184.216.119 unreachable, length 68
09:29:47.116668 IP 1.2.3.4 > 10.0.0.1: ICMP host 93.184.216.119 unreachable, length 68
09:29:47.119289 IP 10.0.0.1.54691 > 93.184.216.119.80: S 717252699:717252699(0) win 14600 <mss 1410,sackOK,timestamp 903626689 0,nop,wscale 7>
09:29:50.120591 IP 1.2.3.4 > 10.0.0.1: ICMP host 93.184.216.119 unreachable, length 68

So it looks like SNAT on server A is working but somehow it is unable to connect to the requested website. Server A iptables list:

SNAT       all  --  10.0.0.1             anywhere            to:1.2.3.4

Server A ip rule list:

0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

Part of server A 'route -n':

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.0.1        0.0.0.0         255.255.255.255 UH    0      0        0 tun0

Could the gateway being 0.0.0.0 have something to do with it?

share|improve this question
1  
This is not a pure routing issue. You cannot communicate with the rest of the world using 10.0.0.1/32. There has to be some NAT. So what does the other system do with the packets? You can track them with tcpdump -i tun0 -n. –  Hauke Laging May 16 at 22:14
    
@HaukeLaging I have edited my original post with tcpdump info –  Martin May 17 at 5:24
    
You should not use route -n but ip route. I guess the 0.0.0.0 doesn't matter because tun0 is a POINTOPOINT connection. Probably the 0.0.0.0 just means "no gateway IP has been set". I must admit I have no idea what's up there. –  Hauke Laging May 19 at 8:08
    
Ok, thanks. FWIW, here's part of the ip route output: 10.0.0.1 dev tun0 proto kernel scope link src 10.0.0.2 –  Martin May 19 at 8:12
    
@HaukeLaging Got it working, thanks a lot for your help! Problem was I had added some of the IPs on server A to eth1 which I just found out is not physically connected to the switch at the ISP :-/ . Re-added the IPs to eth0 and it's working now. –  Martin May 19 at 12:52

1 Answer 1

up vote 0 down vote accepted

There are several problems:

  1. It doesn't make sense to route packets to where they come from. I.e. the

    ip rule add from 10.0.0.1/32 table vpn_table
    

    must be left out on server A (ip rule add to... is not necessary either); server A has "normal" routing. You need such a rule on server B (for B's IP address), though.

  2. You need SNAT on server A. Something like

    iptables -t nat -A POSTROUTING -s 10.0.0.1 -j SNAT --to-source 1.2.3.4
    
share|improve this answer
    
Ok, thanks. Not quite working yet, see my edits above. –  Martin May 19 at 7:50
    
@Martin Is routing enabled on server A at all? cat /proc/sys/net/ipv4/ip_forward + iptables -L FORWARD -nv –  Hauke Laging May 19 at 7:56
    
IP forwarding is on (cat /proc/sys/net/ipv4/ip_forward results in 1). iptables -L FORWARD -nv Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination –  Martin May 19 at 8:00

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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