4

I try to route 137.74.9.193 from server A to server B (Ubuntu 16.04).

If i try to ping 137.74.9.193 from Server A it works as expected, but when i try to ping from my personal computer it doesn't work.

plan

Server A:

Public IP (ens3): 213.32.69.16
Public IP: 137.74.9.193
Local Tunnel IP: 10.0.0.1

Server B:

Public IP (eth0): 139.59.131.76
Local Tunnel IP: 10.0.0.2

Configuration on Server A:

nano /etc/network/interfaces

auto lo
iface lo inet loopback

auto ens3
iface ens3 inet dhcp

auto tun1
iface tun1 inet static
    address 10.0.0.1
    netmask 255.255.255.252
    pre-up iptunnel add tun1 mode gre local 213.32.69.16 remote 139.59.131.76 ttl 255
    up ifconfig tun1 multicast
    up ifconfig tun1 arp
    up ifconfig tun1 broadcast
    pointopoint 10.0.0.2
    post-up ip route add 137.74.9.193 via 10.0.0.2 dev tun1
    post-down iptunnel del tun1

Commands executed:

# enable ip forward
$ echo 1 > /proc/sys/net/ipv4/ip_forward
$ echo 1 > /proc/sys/net/ipv4/conf/ens3/proxy_arp

# Add ip to arp to complete the loop.
$ arp -s 137.74.9.193 fa:16:3e:76:31:ea -i ens3 pub

Result Kernel IP routing table:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         213.32.64.1     0.0.0.0         UG    0      0        0 ens3
10.0.0.2        *               255.255.255.255 UH    0      0        0 tun1
ip193.ip-137-74 10.0.0.2        255.255.255.255 UGH   0      0        0 tun1
213.32.64.1     *               255.255.255.255 UH    0      0        0 ens3

Configuration on Server B:

nano /etc/network/interfaces

auto eth0
iface eth0 inet static
        address 139.59.131.76
        netmask 255.255.240.0
        gateway 139.59.128.1
iface eth0:0 inet static
        address 137.74.9.193
        netmask 255.255.255.255
        broadcast 137.74.9.193

auto tun1
iface tun1 inet static
        address 10.0.0.2
        netmask 255.255.255.252
        pre-up iptunnel add tun1 mode gre local 139.59.131.76 remote 213.32.69.16 ttl 255
        up ifconfig tun1 multicast
        up ifconfig tun1 arp
        up ifconfig tun1 broadcast
        pointopoint 10.0.0.1
        post-down iptunnel del tun1

Commands executed:

# enable ip forward
$ echo 1 > /proc/sys/net/ipv4/ip_forward

# Route to tun1
ip route add 10.0.0.1 dev tun1

Kernel IP routing table:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gateway         0.0.0.0         UG    0      0        0 eth0
10.0.0.1        *               255.255.255.255 UH    0      0        0 tun1
10.19.0.0       *               255.255.0.0     U     0      0        0 eth0
139.59.128.0    *               255.255.240.0   U     0      0        0 eth0

Thanks for any help :)

UPDATE (14.11.2016): Add route commands on Server B

envoyr
  • 43
  • 7
  • 3
    Does server B have a route back to your client? – Mark Riddell Nov 01 '16 at 18:22
  • Also, what does the network between your pc and server A look like? Does every router have a route to 178.0.0.x pointing towards A? – hertitu Nov 02 '16 at 00:42
  • All routers have a route to server A. When i try to traceroute, the last hop call me that the host is not found. – envoyr Nov 03 '16 at 06:49
  • Is ip forwarding enabled on A? Does B have a route back to your pc? What do you mean with "host is not found" exactly? And when you reply please use `@username` so that we get a notification, thanks! – hertitu Nov 06 '16 at 17:50
  • Find the first thing that doesn't work (where the packet or the reply gets stuck) and think about why it should work. – David Schwartz Nov 11 '16 at 21:02
  • @hertitu I've updated my question, and added more commands that I've used. Now the traceroute goes also to the server A, from there it takes a timeout. Currently i have no idea why. – envoyr Nov 11 '16 at 21:23
  • @MauricePreuß Does server A have a route back to the source of the packet it received. Does it go to the right place? Does that machine receive the packet? Keep troubleshooting. – David Schwartz Nov 14 '16 at 19:54
  • @DavidSchwartz i used tcpdump (on server A) and i see "ICMP echo requests..." while my pc (external network) do a ping to the server A. But my pc answers that i lost packets every time. I think for me `iptables -t nat -A PREROUTING -d 137.74.9.193 -j DNAT --to-destination 10.0.0.2` `iptables -t nat -A POSTROUTING -j MASQUERADE` works, but i don't know if it is the right way. All commands that i used are in the question on top. – envoyr Nov 14 '16 at 21:16

1 Answers1

1

As far as I can tell from the information in your question, your problem is that

arp -s 137.74.9.193 fa:16:3e:76:31:ea -i ens3 pub

doesn't do what you think it does. This command creates a new ARP table entry on your server, such that if your server was to send packets over ens3 to 137.74.9.193 it won't do any ARP requests because you already specified a destination MAC address.

But you also need to ensure that the router knows to send the packets to your server. The router will send an ARP request for 137.74.9.193. But since that IP address is not assigned to any interface on your server, your server won't respond to these ARP requests.

To make that work you will need to enable proxy ARP, which you can do with this command:

echo 1 > /proc/sys/net/ipv4/conf/ens3/proxy_arp

If you use that command instead of the arp command, I think it will work. (I know for a fact that this works with the peer IP of a point-to-point interface. I have not tested the same setup with a routing table entry sending the traffic over a tunnel interface, and I don't know with certainty whether that requires additional steps.)

If the ISP hosting Server B filter traffic based on source IP address you may not be able to send packets from there using 137.74.9.193 as source address. If you ping 137.74.9.193 from outside and capture ICMP packets on eth0 on Server B you should see whether ICMP echo responses are being sent on that interface.

If you find that Server B is sending ICMP echo responses and they never reach their destination, the most likely explanation is that the ISP is filtering based on source IP address.

In that case you have two options. You can either contact the ISP and explain that you need to originate packets with this source IP such that they can update their filter. Or you can tunnel the return traffic through Server A.

The simplest way to tunnel return traffic through A is to create a routing table on B which looks like this:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         *               0.0.0.0         UG    0      0        0 tun1
213.32.69.16    gateway         255.255.255.255 UG    0      0        0 eth0
10.0.0.1        *               255.255.255.255 UH    0      0        0 tun1
10.19.0.0       *               255.255.0.0     U     0      0        0 eth0
139.59.128.0    *               255.255.240.0   U     0      0        0 eth0

This will however make 139.59.131.76 unreachable from the rest of the internet. If you want B to be reachable through both IP addresses simultaneously you need to create two different default routes and a routing policy to choose between them based on the packet source IP.

kasperd
  • 29,894
  • 16
  • 72
  • 122
  • Server A responds to ARP requests and when i use tcpdump (on server A) i see "ICMP echo requests" when i try to ping it from my pc (external network). But my pc answers packets lost every time. PS: I already tried but it doesn't working: `iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE` `iptables -A FORWARD -i tun1 -j ACCEPT` – envoyr Nov 14 '16 at 14:35
  • @MauricePreuß I have updated my answer with a bit more information. Also see http://serverfault.com/a/586551/214507 – kasperd Nov 17 '16 at 21:18