[Vyatta-users] Glendale Remote Access L2TP outside-nexthop
Hi, I was messing with Glendale today and with the new remote access features. I've setup a simple lab test: VPNClient(192.168.22.2)---Vyatta(doing NAT)-Internal Network(192.168.10.0/24) First with PPTP: 1,2,3 and it was up and running. Cool! Moving to L2TP/IPsec: 1,2 and I've nailed it. Sort of. There is this mysterious command outside-nexthop. Next hop where ? Since I'm directly connected to Vyatta's external interface there is no next hop. Glendale does not let me to forget the outside-nexthop. So I've entered 192.168.22.1(the Internet gateway of my lab). When I'm connecting I'm placed into an indefinite state of connecting (Windows XP SP2 VPN client). Starting Wireshark I can see that IKE MM and QM negotiations went fine, but it appears there is a problem with the L2TP tunnel. The VPN client is using 192.168.22.2. So I've replaced the outside-nexthop192.168.22.1 with outside-nexthop192.168.22.2. And I'm able to connect. Changing the lab topology: VPNClient(192.168.22.2)---Vyatta(Routing)---192.168.30.0/24---Vyatta(doing NAT)---Internal Network(192.168.10.0/24) And using as the outside-nexthop 192.168.30.1(the IP address of Vyatta(Routing)) I can successfully connect. 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. I must say it was really easy to setup a VPN server with Glendale(exception the outside-nexthop). Although I did not mess with certificates yet. But so far so good. 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. Some more tests(certificates, NAT scenarios, Radius) and I will have a nice subject for some articles. By the way, Glendale appears to be faster and better from any point of view(my opinion). It's a pleasure to play with it. Looks like someone(the Vyatta team) has really worked a lot.:-) Cheers! Adrian ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
[Vyatta-users] DHCP server issues
Hello -
I'm new here and have downloaded and installed Vyatta 3.0. I am
testing it out now and followed the Quick Evaluation Guide. Everything
seems to be working except for the DHCP server - I can't get it to
hand out addresses. If I connect a laptop to the LAN port and send
DHCPDISCOVERs I get no response. If I configure the latpop for a
static address on the same subnet as the LAN interface
(192.168.1.0/24) everything works fine - I can get through the router
(NAT and the firewall seem to be working as well). My DHCP server
config is below - this should be very simple, but after a few hours I
can't figure out why it's not working.
Any ideas would be much appreciated.
Thank you,
-Matt
[EMAIL PROTECTED] show service dhcp-server
shared-network-name LAN-pool {
subnet 192.168.1.0/24 {
start 192.168.1.100 {
stop: 192.168.1.199
}
dns-server 1.1.1.1
dns-server 1.1.1.2
default-router: 192.168.1.1
wins-server 3.3.3.3
wins-server 3.3.3.4
}
}
[edit]
[EMAIL PROTECTED]
___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Graphing bandwidth: how do you do it?
Are you wanting just the toal bandwidth in/out of each interface, or are you wanting it broken down by which subnets/hosts are using how much bandwidth. For the former, MRTG (or maybe cacti, but I prefer MRTG) is your best bet. For the latter, I use bandwidthd reporting to a seperate postgres+httpd server. -- Aubrey Wells Senior Engineer Shelton | Johns Technology Group A Vyatta Ready Partner www.sheltonjohns.com On Feb 20, 2008, at 12:41 PM, [EMAIL PROTECTED] wrote: All, I have been trying to get a bandwidth monitoring / graphing utility to work now and have hit a hard road. I have tried to install the 'real' webmin because they have a nice easy way to show traffic in / out, but to no avail. I have started the snmp way via MRTG, but it will take me a while to set up and configure. Can anyone recommend the easiest way to watch the traffic on my vyatta box interface(s)? I'm sure I'll eventually get MRTG to work-- but maybe there is a cleaner way? Thanks in advance, Aaron p.s. Out of curiosity, has anyone gotten 'Webmin' (the official package) to install on a vyatta machine? I resolved various dependencies, but still cannot connect to it. ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Graphing bandwidth: how do you do it?
Hi there, Thank you for your email. I am currently away on reservist and will only be back on the 3rd March 2008. My access to email during this period will be limited. If there is any urgent matter that require attention, please contact Choon Kiat ([EMAIL PROTECTED]) during this period and cc me in the email. Warmest regards, Daren Tay Senior MIS Hardware Zone Pte Ltd ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Glendale Remote Access L2TP outside-nexthop
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
Re: [Vyatta-users] list reply-to address
Hi there, Thank you for your email. I am currently away on reservist and will only be back on the 3rd March 2008. My access to email during this period will be limited. If there is any urgent matter that require attention, please contact Choon Kiat ([EMAIL PROTECTED]) during this period and cc me in the email. Warmest regards, Daren Tay Senior MIS Hardware Zone Pte Ltd ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] list reply-to address
Done. After vascillating for a while, I finally caved on this. Replies now go back to the list rather than the original poster. Please be careful if you need to send something direct. As an aside, I have no idea why vyatta-users was setup differently than vyatta-hackers. They should have had the same behavior. -- Dave _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aubrey Wells Sent: Wednesday, February 20, 2008 11:23 AM To: vyatta-users@mailman.vyatta.com Subject: [Vyatta-users] list reply-to address I notice that when I mail the hackers list, the reply-to address is automatically set to [EMAIL PROTECTED] but when I mail to vyatta-users I have to manually set the reply-to address to vyatta-users@mailman.vyatta.com or I frequently get replies straight to my inbox rather than to the list. Can you please adjust the configuration of the users list to set the reply-to address to vyatta-users? It drives me a little crazy. ;-) -- Aubrey Wells Senior Engineer Shelton | Johns Technology Group A Vyatta Ready Partner www.sheltonjohns.com ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
[Vyatta-users] Graphing bandwidth: how do you do it?
Have you looked at cacti ? Also most NMS platforms perform some graphing i.e jffnms ( free open nms ) ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Glendale Remote Access L2TP outside-nexthop
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
Re: [Vyatta-users] Glendale Remote Access L2TP outside-nexthop
Hi Adrian, Yes, you are right that such a setup is not currently supported. Looks like it will require defining two different connections in Openswan configuration and also making sure the L2TP server can serve clients from both. Maybe we can look into extending the configuration syntax to allow multiple instances. An-Cheng Adrian F. Dimcev wrote: 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 ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
