Creating FOU tunnels to the same destination IP but different port

Creating FOU tunnels to the same destination IP but different port

[Kostas Peletidis]

Hello,

I am having trouble with a particular case of setting up a fou tunnel
and I would really appreciate your help.

I have a remote multihomed host behind a NAT box and I want to create
a fou tunnel for each of its IP addresses, from my machine.

A typical case would be something like that (output from the local machine):

# ip tun
ipudp09602: ip/ip remote 135.196.22.100 local 172.31.0.140 ttl 225
ipudp00101: ip/ip remote 148.252.129.30 local 172.31.0.140 ttl 225
ipudp09604: ip/ip remote 77.247.11.249 local 172.31.0.140 ttl 225
tunl0: any/ip remote any local any ttl inherit nopmtudisc
ipudp00102: ip/ip remote 213.205.194.18 local 172.31.0.140 ttl 225

However, if the remote end has the same IP address with the remote end
of an existing tunnel (but a different remote port)
tunnel creation fails. In this example there is already a tunnel to
135.196.22.100:32270 and I wanted to create a new tunnel
to 135.196.22.100:24822 as below:

# ip link add name ipudp09603 mtu 1356 type ipip \
  remote 135.196.22.100 \
  local 172.31.0.140 \
  ttl 225 \
  encap fou \
     encap-sport 4500 \
     encap-dport 24822

RTNETLINK answers: File exists

The remote IP addresses in this case are identical because there is a
NAT box in the way, but the port numbers are different. The source
address and port are the same in all cases.

I noticed that ip_tunnel_find() does not check port numbers - being IP
and all - so I am thinking that a not-so-elegant way to do it is to
get the port numbers from the netlink request and have
ip_tunnel_find() compare them against encap.{sport, dport} of existing
tunnels.

Is there a better way to create a second fou tunnel to the same IP
address but a different port? Use of keys as unique tunnel IDs maybe?
Any feedback is appreciated. Thank you.


Regards,
Kostas

Re: Creating FOU tunnels to the same destination IP but different port

[Tom Herbert]

On Fri, Apr 13, 2018 at 9:57 AM, Kostas Peletidis <kpeletidis@gmail.com> wrote:
> Hello,
>
> I am having trouble with a particular case of setting up a fou tunnel
> and I would really appreciate your help.
>
> I have a remote multihomed host behind a NAT box and I want to create
> a fou tunnel for each of its IP addresses, from my machine.
>
> A typical case would be something like that (output from the local machine):
>
> # ip tun
> ipudp09602: ip/ip remote 135.196.22.100 local 172.31.0.140 ttl 225
> ipudp00101: ip/ip remote 148.252.129.30 local 172.31.0.140 ttl 225
> ipudp09604: ip/ip remote 77.247.11.249 local 172.31.0.140 ttl 225
> tunl0: any/ip remote any local any ttl inherit nopmtudisc
> ipudp00102: ip/ip remote 213.205.194.18 local 172.31.0.140 ttl 225
>
> However, if the remote end has the same IP address with the remote end
> of an existing tunnel (but a different remote port)
> tunnel creation fails. In this example there is already a tunnel to
> 135.196.22.100:32270 and I wanted to create a new tunnel
> to 135.196.22.100:24822 as below:
>
> # ip link add name ipudp09603 mtu 1356 type ipip \
>   remote 135.196.22.100 \
>   local 172.31.0.140 \
>   ttl 225 \
>   encap fou \
>      encap-sport 4500 \
>      encap-dport 24822
>
> RTNETLINK answers: File exists
>
> The remote IP addresses in this case are identical because there is a
> NAT box in the way, but the port numbers are different. The source
> address and port are the same in all cases.
>
> I noticed that ip_tunnel_find() does not check port numbers - being IP
> and all - so I am thinking that a not-so-elegant way to do it is to
> get the port numbers from the netlink request and have
> ip_tunnel_find() compare them against encap.{sport, dport} of existing
> tunnels.
>
> Is there a better way to create a second fou tunnel to the same IP
> address but a different port? Use of keys as unique tunnel IDs maybe?
> Any feedback is appreciated. Thank you.
>
Hi Kostas,

This is an interesting problem, thanks for reporting it! FOU in this
case is being used as modified ipip tunnel so the check of uniqueness
is only based on local and remote addresses for an IP tunnel. As you
point out, the port information does provide more specific information
that could be be used to distinguish between the tunnels (especially
on receive). Using the information is tricky since the FOU and ipip
layers are pretty much independent. The keys approach might be
possible. I'll try to take a closer look.

Tom

>
> Regards,
> Kostas