IPIP Tunnel Issues

smugcloud · 09-19-2017, 08:25 PM

Hi Everyone,

I am trying to learn IPIP tunnels and have the setup below across two VM's in separate public clouds. The tunnel and routes seem valid, yet I am unable to ping the `ipiptun` interface address across the machines.

I believe there is a way to accomplish this without Netfilter rules, and have not created any. What am I missing to accomplish this?

Machine A: Public IP is 34.209.x.x

Code:

# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 0a:a2:d5:b4:41:5c brd ff:ff:ff:ff:ff:ff
    inet 172.31.5.73/20 brd 172.31.15.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::8a2:d5ff:feb4:415c/64 scope link
       valid_lft forever preferred_lft forever
12: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1
    link/sit 0.0.0.0 brd 0.0.0.0
14: tunl0@NONE: <NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN group default qlen 1
    link/ipip 0.0.0.0 brd 0.0.0.0
23: ipiptun@eth0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 8981 qdisc noqueue state UNKNOWN group default qlen 1
    link/ipip 34.209.x.x peer 104.199.x.x
    inet 9.42.2.1/32 scope global ipiptun
       valid_lft forever preferred_lft forever
# ip route show
default via 172.31.0.1 dev eth0
9.42.1.0/24 dev eth0  scope link
172.31.0.0/20 dev eth0  proto kernel  scope link  src 172.31.5.73
# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

Machine B: Public ip is 104.199.x.x

Code:

# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc mq state UP group default qlen 1000
    link/ether 42:01:0a:8a:00:03 brd ff:ff:ff:ff:ff:ff
    inet 10.138.0.3/32 brd 10.138.0.3 scope global ens4
       valid_lft forever preferred_lft forever
    inet6 fe80::4001:aff:fe8a:3/64 scope link
       valid_lft forever preferred_lft forever
3: tunl0@NONE: <NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
5: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
11: ipiptun@ens4: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1440 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip 104.199.x.x peer 34.209.x.x
    inet 9.42.1.1/32 scope global ipiptun
       valid_lft forever preferred_lft forever
# ip route show
default via 10.138.0.1 dev ens4
9.42.2.0/24 dev ens4 scope link
10.138.0.1 dev ens4 scope link
# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

mabo1 · 10-06-2017, 08:49 AM

Hi,

I have been thinking about trying something similar. I am no expert on the subject so not likely to be much help.

I would have expected to see some reference to the the tunnel device in the routing table. If you have ever played with a VPN which is an encrypted tunnel you would see the routes are updated and usually the default route is pointing to the tunnel device. Now this may not be needed if only some of the traffic is required to go through the tunnel, but I am surprised to not see the "tun" device in the table.

I am curious on the interaction between an IP tunnel and the firewall. I assume that the tunnel works by wrapping the actual packet with a new packet and different IP address, and at the the other end it strips that outer packet and are left with the original packet. Does this happen before or after passing through the firewall?

mabo1 · 10-06-2017, 08:57 AM

May help if you have not seen it before.

http://www.deepspace6.net/docs/iproute2tunnel