On Tue, 07 Jun 2016 13:34:35 -0700
pbar...@netprotec.com wrote:

> This is not currently supported in quagga/nhrp or opennhrp. In
> opennhrp it is difficult to implement. In quagga/nhrp it can be
> implemented a bit easier, but it would also require kernel support. I
> have not had need for this - rarely one would have multiple vpncs
> behind same NAT box. Though, this can become more problematic with
> carrier grade nat getting more popular (usually in 4g/lte wireless,
> and in some countries that just did not get public IPs enough).
> 
>  Cisco does not support this on traditional dmvpn setup. Though, the
>  newer flexvpn implementation should be able to handle this.
>  
>  Thank you both for the quick and clear clarification.  However, if
> one side, or both, used UPnP to port map that should solve this
> issue. Any thoughts or experience with this?

Short answer: no, it will not help.

Long answer: the problem is due architectural implementation
details.

If one end is NATted, it's practically not harmful at all (it forces
IPsec NAT-T and may increase per-packet encapsulation overhead with few
bytes). If both are NATted to different IPs the direct tunnels will not
establish unless there's port forwarding (so upnp should help on this).
The are mainly problems on ipsec / IKE level.

But if both are NATted to same public IP, you get different problem.
DMVPN works by combining GRE+NHRP+BGP (or some other routing protocol).
It is the routing protocols job to exchange prefix routes; so basically
it floods the routers table with something like (172.16.0.0/24 assumed
to be the GRE IP addresses):
10.1.0.0/16 via 172.16.0.1
10.2.0.0/16 via 172.16.0.2

And the NHRP layer adds routes (per each direct ipsec tunnel):
172.16.0.1 dev gre1
172.16.0.2 dev gre1

and finally nhrp adds the nbma gre bindings also to neighbor table
(arp):
172.16.0.1 dev gre1 lladdr 1.2.3.4
172.16.0.2 dev gre1 lladdr 1.2.3.4

So when a packet is sent to 10.1.x.y or 10.2.x.y, the end result in
routing is still different, but after gre tunnel nexthop lookup you end
up having same public IP 1.2.3.4. This is now disconnected from the
IPsec SAD and it may pick either IPsec tunnel to send the packet.

The kernel side fix is to add some system internal tunnel id. Or
perhaps use the already currently existing xfrm reqid for this purpose.
The xfrm/gre/neigh framework then needs to be extended to be able to
have this as additional match from the neighbor lookup (or potentially
the device route nhrp created earlier). Additionally nhrpd needs
stronger integration with the ipsec daemon so it can exchange the
'reqid' or other similar id with both the ipsec daemon and the kernel.

So no, you can't have two different vpnc devices behind same NAT
address unless the code in the linux kernel, the ipsec daemon and the
nhrp daemon are extended to work together to distinguish that
situation. This is internal implementation detail.

The other solution would be what Cisco did in FlexVPN - to not use
multipoint GRE tunnel, but create tunnel device per connection, and
have the binding info in the tunnel device. Thus the last routes would
be:
172.16.0.1 dev gre1
172.16.0.2 dev gre2

And now the kernel's xfrm/ipsec policies can distinguish which policy
to apply based on the device. However, the overall changes would be
probably more extensive since this would require:
 - nhrp to create/delete the interfaces on demand
 - ipsec daemon to know which device is for each connection to create
   correct SDP entries

Cheers,
Timo

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
opennhrp-devel mailing list
opennhrp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opennhrp-devel

Reply via email to