1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Development News -- Linksys Quick VPN Solution...almost there!

Discussion in 'Cisco Small Business Routers and VPN Solutions' started by eric_stewart, Jan 16, 2007.

  1. eric_stewart

    eric_stewart Super Moderator Staff Member Member

    I am able to get a reliable, solid QuickVPN connection to my RV042 at home. For those unfamiliar with the thread, search for QuickVPN threads using the search function and also this link, http://www.breezy.ca/?q=node/86, on the Breezy! site (www.breezy.ca) before reading futher... Don't forget to use the search function. use QuickVPN as a keyword.

    I should point out that I am behind 2 NAT’ng devices as well. The RV042 might be behind a PIX, but it’s working fine as long as I forward ISAKMP, ESP and (optionally) NAT-T traffic to it. I’m using QuickVPN 1.0.47 and the latest beta code for the RV042. Forwarding these protocols isn’t a bandaid or a patch. I realize in looking closely/closer at how QuickVPN works that I had made incorrect assumptions of how QuickVPN works but now have my mind around it. That is why my solution is working now, since I am forwarding all the traffic that the VPN connection might need to the RV042. The “Negotiating IP Security Policies” message I was getting before I fixed my configuration was because I wasn’t allowing IKE messages through to the RV042. All negotiation of keys, ciphers and hashing algorithms happens during IKE Phase I and I was unintentionally blocking it by not allowing it through. Furthermore, I had to forward all the ESP (IKE Phase II) traffic to the RV042. Makes sense, though with the PIX’s VPN passthrough feature on (see “fixup protocol esp-ike” in the configuration notes) this is probably unnecessary.

    Another tester and I did another 1.5 hours of testing tonight. I am in a hotel, behind the aforementioned NAT’ng routers and the other tester was on his home network, also trying to connect to my network with credentials I supplied him. We think that the problem he had (and generally with QVPN) might be related to QuickVPN connections that are attempted from clients who are themselves behind QuickVPN routers.

    FWIW, I had similar results when using a dialup connection (sheesh…old tech!) and a public IP address. I was able to connect 100% of the time.

    I was asked my someone on Linksysinfo.org why I would want to VPN to my RV042 when I can use the Cisco VPN solution. Here was my answer:

    "Actually, it's a philosophy thing. A common axiom in the network security business is "separation of services". While the PIX is capable of supporting/terminating a VPN, its primary purpose is to be an edge firewall, establishing one perimeter in a multi-tiered, multi-zone network. The other thing is, if I establish the VPN to the RV042, I am taking advantage of its hardware-accelerated encryption VPN capability...thus (theoretically) improving throughput. The PIX 501 that I'm using supports software-only encryption VPNs....adding a measurable burden to the little chipmunk-on-a-rubber-band AMD 133 MHz processor."

    This is going to be a slick solution when they put the final touches to it. I particularly like the ability to generate a certificate on the RV042, and the mechanism where the client can refuse to connect if the server’s certificate isn’t found.

    /Eric
     
  2. YeOldeStonecat

    YeOldeStonecat Network Guru Member

    Heehee.....cute.

    Curious how you'll find the reliability over the long haul. I'm getting mixed as time goes on with a client that I did my first QuickVPN deploy with.
     
  3. TheCiscoKid

    TheCiscoKid LI Guru Member

    How were you able to get past "Negotiating IP Security"?

    It seems I'm having this problem with my RVS4000. Only I am using the router as my home gateway, so it doesn't sit behind any other routers...

    -Ryan
     

Share This Page