Hi An-Cheng, Thanks for your answer. One thing comes on my mind right now: Allow me to draw a simple and maybe common situation: Say Glendale has three interfaces: External, Internal and a so-called "Wireless DMZ". Although it's a little bit archaic, some people prefer to secure their WLANs using VPN. Thus they create an anonymous DMZ where they place an AP. Then they "VPN into" the Internal network from this wireless DMZ. There might be certain situations where this would be a convenient solution(say some schools network designs). So we need to enable "vpn l2tp" on two interfaces: External and Wireless DMZ. The wireless clients are directly connected(%direct) while the road warriors are not. Looking at Glendale, currently it seems that this is not doable. Thanks, Adrian
An-Cheng Huang wrote: > Hi Adrian, > > You're exactly right on the issues you pointed out. > > (1) Requiring some "vpn ipsec" parameters for "vpn l2tp" is a bit > inconvenient, and, as you said, it may mislead users to think that the > IKE/ESP settings in "vpn ipsec" will also apply to "vpn l2tp" (they > don't). The main issue here is interoperability with site-to-site VPN. > The "ipsec-interfaces", "nat-traversal", and "nat-networks" parameters > from "vpn ipsec" (required for "vpn l2tp") belong to the "global" > IPsec configuration for Openswan, so setting them in "vpn l2tp" may > change the site-to-site behavior as well, which may not be desirable. > > (2) The "outside-nexthop" parameter is sort of redundant. It > corresponds to the "leftnexthop" parameter in the Openswan connection > configuration. The problem here is that if "leftnexthop" is not set, > it defaults to "right", which won't work unless the client is directly > connected. We could set it to "%defaultroute" by default, but that > will require changing the global IPsec configuration, which, again, > may change the site-to-site behavior. The current approach is to let > the user configure it (using "outside-nexthop"). I'll investigate > further to see if we can simplify this. > > Thanks for playing with the remote access VPN feature! Let us know if > you find other issues. > > An-Cheng > > Adrian F. Dimcev wrote: >> So why do I need this "outside-nexthop" since I already have >> specified a default route through 192.168.30.1 ? >> Since my experience shows that there are problems with NAT devices, >> I've always done my first tests connected directly to the external >> interface of the VPN server. With pre-shared keys. Then with >> certificates. After I know that the VPN server is properly >> configured, I "move" along the path. > >> In the beta docs, page 664, "If the authentication mode is >> pre-shared secret, you must configure the secret using the vpn >> pptp remote-access outside-address <ipv4> command (see page 697)." >> statement does not appear to be correct, neither the command. > >> It would be nice to do all the L2TP/IPsec configuration from the "vpn >> l2tp" node. Without using the "vpn ipsec" node. To make a clear >> distinction between site-to-site and remote access. >> The "vpn ipsec" node gives the "feeling" that the L2TP/IPsec IKE MM >> and QM settings are supposed to be editable(customize the proposals >> from the CLI). Bu it does not appears to be so. > > _______________________________________________ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
