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