Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to discuss Implementing EzVPN with Cisco expert Glenn Fullager. Glenn is a TAC engineer with the Post Sales Support team based in Melbourne, Australia. He is responsible for assisting customers in the AsiaPac region with high-level problems, specializing in the Security and VPN technologies. Feel free to post any questions relating to Implementing EzVPN. Remember to use the rating system to let Glenn know if youve received an adequate response.
Glenn might not be able to answer each question due to the volume expected during this event. Our moderators will post many of the unanswered questions in other discussion forums shortly after the event. This event lasts through June 20. Visit this forum often to view responses to your questions and the questions of other community members.
This is RRI issues with VPN3002 and PIX (501) in EzVPN design. As I am aware that the VPN3002 only able to support one subnet for its encryption domain. Is there any plan to support several subnets behind the VPN3002?
Thanks for your question.
At this time there is no plans for multiple subnet support with NEM on the 3002, sorry about that.
A way to work around this though, if you have a router behind the 3002 that connects to other subnets, is PAT all the traffic as it goes thorugh this router to an IP address on the locally connected network, then it'll be sent over the tunnel as though it came from the local subnet. a pain I know, but at his point it's the easiest workaround.
Thanks for your question.
The limitation is a 3002 limitation, regardless of what it connects to (PIX, IOS, 30xx), so yes, it still applies.
Keep in mind though we're talking about NEM mode here, theoretically (although can't say I've tested it personally), client mode should allow multiple networks to connect. Of course with client mode, you can't see or connect to each of the hosts behind the 3002 from the main network.
I guess I could expand on my scenerio a bit and see if you have any insights. I have a remote location in Australia using a PIX501 with EZVPN to connect back to a VPN3005 here to my main facility in the US. In the US, I have a frame relay WAN for multiple sites. The connection works great from Australia to our main site here in the US, but now I would like Australia to access a site that is on my frame relay here in the US. I can't seem to get the connection to be made to any subnet other than at our main site. One other thing that is strange, I can ping the inside(private) interface of the 3005 from my main site, but cannot ping the inside(private) interface of the 3005 from any other subnet on the WAN. Is there a setting that I'm missing there? Any help would be appreciated.
Sounds like you don't have static routes for these FR subnets in the 3005. Go under Config - System - IP Routing 0- Static Routes and add them all in.
Adding these should also allow the remote 501 to access these subnets.
In the 3002, there is a section to add static route for the return traffic to multiple subnets behind the 3002. Provided that I use The Network Extension mode, I suspect this issue can be solved. Pls correct me if I am wrong since I am about to implement this.
Thanks for your question.
If we're still talking about the one-subnet limitation here, then no, adding static routes into the 3002 won't resolve that.
There has been some conjecture about the usefulness of being able to add static routes onto the 3002, considering it has a one-subnet limitation towards the head-end. Really the only reason I can see for adding static routes pointing out the private 3002 interface is so you can manage the box from different subnets. Again though, this will NOT allow you to route those subnets over the VPN, or said another way, those remote subnets will NOT appear on the main site network and therefore will not be routable.
In NEM, the only way to have >1 network routed across the tunnel is to NAT/PAT those other networks to some address on the one routed network. You will have a router separating those networks behind the 3002, so you should be able to configure NAT/PAT on it relatively easily. Of course this doesn't help you access those hosts from the main site, which is the main difference between client mode and NEM.
I have another question. I have a 3003 Hardware Client running ver 4.0.1 Rel-k9.bin image. However, the PIX that it will establish a tunnel is only DES capable. I need to setup the 3002 so it uses DES. Is this something to do w selecting a different image file or is there something I need to change on the 3002 GUI side? I don't plan to get a 3DES license for the PIX.
You shouldn't need to do anything here. The 3002 will try both 3DES and DES proposals until it finds a match with the PIX.
Hi Glenn, I am new to VPN on firewalls, so bear with me. I have a PIX ver. 6.3 with one of the interfaces dedicated to wireless employees and visitors. I am handing out different source IP's to control the access. I want employees to have full access to inside and outside networks. The visitors should have access to our public webservers on the inside and full outside access to the Internet, but nowhere else. I also want to block several ports from leaving that network like IRC and backdoor ports. Documentation specifies that crypto access-lists determine what to protect, not what to allow. Regular access-lists determine what to allow. This is not working. My security levels are outside=0, inside=100, wireless=10. I cannot block the visitor from being able to come inside. I have tried crypto access-lists and regular access-lists. I am thoroughly confused on the process trafffic goes through on the PIX when you have regular access-lists and crypto access-lists. How do you "protect" everything that you want to allow, but not allow the clients to go anywhere they want?
Thanks for your question.
I'm a little confused why you're using crpyto access-lists here, are the wireless users and/or visitors VPN'ing into the PIX interface, or just connecting straight in? How are you allocating different IP addresses, with different VPN group's and different VPN pools? I'm going to assume these users are VPN'ing into the wireless interface, so you'll have to correct me if I'm wrong.
You're correct in stating that VPN users generally have direct access through the PIX. This is because you have the command "sysopt connection permit-ipsec" in your config, this command specifically allows IPSec traffic to bypass all the normal checks and get straight in. Because all the traffic coming in is IPSec traffic, it gets difficult to specifically permit/deny certain traffic, cause all the PIX ever sees (when the packet comes in on the interface and hits the standard ACL) is the IPsec packet, not the actual data packet inside it.
The easiest way to filter out traffic is to change your NAT 0 ACL. This ACL defines traffic that is not to be NAT'd, or in other words, your IPsec traffic. Since NAT happens BEFORE IPSec in the PIX, you have to tell the PIX specifically not to NAT the packet so that it will still match the encryption ACL. Anyway, if you only want these visitors to get to specific hosts on the inside then change this ACL to only define traffic FROM these certain hosts going TO the VPN pool of visitors addresses (you can have more than one line in your NAT 0 ACL). In this ACL also define all traffic FROM the inside hosts going TO your wireless users so they can still get to everything else.
I'm Just about as green as they get with the wireless realm so this will probable raise more questions then answer but here goes - -
Currently, we here at the local site are using an ACS server and 1200 series access points running across VLANS using LEAP! We support approx 500 users here with a simo-login of maybe 100, but also vlan it across to all other sites.
I've been mandated by corp to convert to VPN for the intra-site employees and contractors. I've been hammering the web pages in Cisco and out for and found a whole lot of info that doesnt seem to add up to the whole enchilada.
what are my
How should this be done correctly?
any and all is appreciated,
By "simo-login of maybe 100", do you mean the number of simultaneous logins is usually around 100 out of your 500 users?
And by "converting to VPN", what are you referring to exactly? Do you have to have the remote users VPN into some device on your corporate network and authenticate to the ACS server, then use this VPN for access to your corporate hosts?
If so then it sounds like you need a VPN client on each wireless PC, and have them connect into either a PIX, router or VPN concentrator automatically. The VPN client supports auto-initiation of the VPN tunnel specifically for wireless clients. You can read up on this here (http://www.cisco.com/univercd/cc/td/doc/product/vpn/client/rel4_0/admin_gd/vcach3.htm), hopefully that'll give you some background information.
If I'm barking up the wrong tree with what you want to do here please let me know.
Thanks for the quick response,
Correct. About 100 simultaneous logins at any given time. But there will be no remote users, this will be for in "in building wireless network" not any remote users outside building.
Boy, Im sorry but I'm not to sure on what I mean by "converting", other then right now we are authenticating via LEAP on the ACS server through the 1200 series access points and Corp has recommended (intensely) to convert all authentication via VPN.
I guess my biggest question is can I keep all the same hardware and just make software configuration changes to accomplish?
Or do I need to wipe the slate and start anew?
Or a mixture of both!
I'll check out the link and see if that clears things up a bit.
Again thanks for your time and expertise.
Sorry for the delay in getting back to you.
I guess I'm still al little confused by what your management is asking here. VPN is NOT an authentication scheme, it's a method of encrypting data for transmission over a network, usually private data over a public network. If you're already authenticating via LEAP then this should be enough to stop unauthorized users access into your access points. Implemeting a VPN will not make any difference to how you authenticate to the access points, it will just mean that the data between your laptop and the access point is encrypted or not.
This is regarding RRI specification. What kind of routing protocol does the RRI use?? From the head-end Concentrator`s routing table, it shows that the route from VPN3002 is learned through RIP . Does it mean that RRI uses RIP protocol to advertised 3002`s route through the encrypted tunnel ???
If it is the case, does all the timers(hold-down, hello, etc) on the RIP apply also to the RRI ??
Will be appreciate for your assistance.
The routes aren't really advertised over the tunnel per se.
Depending on your setting on the head-end concentrator under the Config - system - IP Routing - RRI section, the head-end conc will add a route to it's own routing table when the tunnel is established. For example, if you have 3002's doing NEM mode, then enable the "Network Extension RRI" mode under the routing section on the head end. When the tunnel is established the head-end will determine the remote subnet during the tunnel negotiation and add that subnet to its own routing table. Then, depending on whether you have RIP or OSPF configured on your Private interface, the head end conc will advertise that subnet and any others subnets it has using the routing protocols specifications. For RIP, for example, it will send out a routing update every 60 seconds as normal, for OSPF it does do all he normal hello's, LSA's, etc.
If the tunnel ever goes down, that subnet is removed from the routing table and not advertised any longer in any future routing update packets.
Not sure why it shows up as being learned via RIP, never noticed that before. I do know that it's not actually advertisd over the tunnel though like a standard RIP route, it's added into the routing table during tunnel negotiation.
This is Engel again. I would like to ask regarding the failover mechanism in EzVPN mode toward to Master & Backup Concentrator at the head-end. I think this function is useless. My testing result is the failover takes as long as THREE minutes to fail-over to the Backup Concentrator in case the Master is not reachable. This is tested with Concentrator v3.5.5 and VPN3002 v3.5.5.
3 minutes is very slow response for a redundancy solution, since many applications are already time-out. I think how the VPN3002 detects that its current head-end already dead is the key problem to the slow fail-over.
Any thoughts how to improve this kind of redundancy mechanism ?
This regarding the VPN3002 as an EzVPN client in NEM mode. How big is the buffer allocated for processing fragmentation and reassembly of packets on the VPN3002? One of our client networks with EzVPN design is suffering a network degradation if transferring large packets (FTP & Lotus Notes). Transfering file as big as 4MB stopped at 100Kb and after a few minutes the FTP client aborted the session. From the VPN3002 IP monitoring counters, the number of "Reassemble Failures" is counting up. We tried to lowering the MTU size at VPN3002 and the head-end Concentrator to 1300 bytes doesn`t help. Still experiencing packet drops at the VPN3002 side. We suspect that the VPN3002 buffer is not enough to process fragment/assembly of packets. Since the VPN3002 specification does not mention anything regarding the BUFFER, I am curious if you know such information internally.
Any insight ?
We are using a 1721 as a router, firewall, and VPN Server. We currently have clients logging on using the Cisco VPN Client; however, we also have three sites that will need to have a robust permanent connection to the office. The software VPN Client does not stay reliably connected for days, and requires periodic relogin with xauth turned on. These sites have dynamic IPs (so I can't set a peer on the 1721), and they each only have one or two computers.
It was suggested (by a VPN Client TAC worker) that we could set up these permanent connections using another router (SOHO91/806) at these locations using EzVPN. The software VPN clients and Lan-to-Lan clients need to be able to see each other.
Is EzVPN a viable solution here? If so, what is the best way to configure EzVPN for the dynamic-to-static Lan-to-Lan connections while still allowing XAuth for the VPN Client connections?
If you configure these remote routers as EzVPN clients, then you don't need to do anything extra on the head end 1721. When a router connects in as an EzVPn client, to the head-end evice it looks just like a software client connecting in.
In the remote routers that you configure as EzVPN clients you'll configure the group name and password just like you have used on the SW VPN clients. The only trouble you may run into here is the fact that someone will have to actually enter in a username/password on the client (either via a web page or on the console directly) before the tunnel will be established. In early 12.3T code you'll be able to configure and save the username/password inot the router configuration also so that the tunnel will always be up regardless.
But in short, yes, this is a viable solution. You'll want to run NEM mode so that the PC's behind the EzVPN clients are contactable by both your head-end devices and your remote SW clients. As I said though, to the head-end device they all look like SW clients connecting in.
Hi Glenn, I´m new about VPN, and need to implement a VPN over a PIX 515 6.1(1) and some remote users with cisco vpn client and others over win 2000 client. I ´ve reading about that and I have some doubts yet, can you give me a very nice and useful Link and/or comments about?
I know that I need an update the IOS in order to get 3DES, but now I need to do some tests.
Thanks in advanced
Hi i have a question about remote administration of a device by a third party, if say a PIX501 is using the EzVPN function to a head end PIX or Router.
We usually manage customers PIX`s remotely via the VPN Client.
If a customer PIX is using EzVPN to there HeadEnd site, as i understand we cant mix EzVPN and shall i say Normal VPN Crypto Commands. So i cannot add a vpnclient on the box as well.
Apart from connecting to the HeadEnd via VPN, then tunnelling to the remote VPN, do i have any other options for remotely managing the remote Pix`s?