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

RV042 VPN woes...

Discussion in 'Networking Issues' started by tuxman, Aug 23, 2006.

  1. tuxman

    tuxman Network Guru Member

    Anyone got any suggestions..

    I'm in the middle of setting up a bunch of retail stores with dsl and RV042's.. There are currently 3 locations (including head office) and then my house aswell. All of the sites have tunnels back to the head office and to my house. The issue is that the tunnels seem to get hung up, once hung one end shows the tunnel connected, the other end shows it disconnected. Linksys's suggestion was to lower the mtu (lowest being 1300) or the firmware was corrupt. I've find it hard to believe that every box I have has corrupted firmware. I've currently got beta firmware running on them and it seems a little better but they still get hung up. I've tried the MTU settings and also didn't really help.

    the only real way to resolve the connections once they are in the inverse states is to reboot the devices, which obviously isn't really an option.

    I'm wondering if it's something in the VPN config that is causing it to get hung up or what else I could do to help fix it.

    Other than replacing the units I'm open to whatever suggestions anyone can come up with.. relaxing the security on the vpn ? I donon. I'm stumped.

  2. tuxman

    tuxman Network Guru Member


    I'm still fighting with Linksys on this issue.

    I have tried everything I can think of.. including the old
    hardware reset
    flash old
    hardware reset
    flash new
    hardware reset

    and still I have tunnel's starting to fail, usually after about 2-3 days. but sometimes longer or shorter. When it happens the only solution is to reboot the router that refuses to disconnect.

    Just last night infact, I lost the tunnel between my non-static site and on of my static ip sites. The static says it's waiting, the non-static says not connected.. I try to connect, and I get a response from the static site that says

    Oct 4 22:00:13 2006 VPN Log received Delete
    SA payload: deleting ISAKMP State #1397
    Oct 4 22:00:14 2006 VPN Log Received Vendor
    ID payload Type = [Dead Peer Detection]
    Oct 4 22:00:14 2006 VPN Log [Tunnel
    Negotiation Info] <<< Responder Received Aggressive Mode 1st packet
    Oct 4 22:00:14 2006 VPN Log Aggressive mode
    peer ID is ID_USER_FQDN: 'email@domain.com'
    Oct 4 22:00:14 2006 VPN Log Responding to
    Aggressive Mode from xx.xxx.xx.xxx
    Oct 4 22:00:14 2006 VPN Log [Tunnel
    Negotiation Info] >>> Responder Send Aggressive Mode 2nd packet
    Oct 4 22:00:14 2006 VPN Log [Tunnel
    Negotiation Info] <<< Responder Received Aggressive Mode 3rd packet
    Oct 4 22:00:14 2006 VPN Log Aggressive mode
    peer ID is ID_USER_FQDN: 'email@domain.com'
    Oct 4 22:00:14 2006 VPN Log [Tunnel
    Negotiation Info] Aggressive Mode Phase 1 SA Established
    Oct 4 22:00:14 2006 VPN Log [Tunnel
    Negotiation Info] Initiator Cookies = 5973 6c76 a766 4d41
    Oct 4 22:00:14 2006 VPN Log [Tunnel
    Negotiation Info] Responder Cookies = 48d7 a0e4 9d6b 3065
    Oct 4 22:00:14 2006 VPN Log [Tunnel
    Negotiation Info] <<< Responder Received Quick Mode 1st packet
    Oct 4 22:00:14 2006 VPN Log we require PFS
    but Quick I1 SA specifies no GROUP_DESCRIPTION
    Oct 4 22:00:21 2006 Connection Refused -
    Policy violation IGMP> on ixp0
    Oct 4 22:00:22 2006 Connection Refused -
    Policy violation IGMP> on ixp0
    Oct 4 22:00:23 2006 VPN Log Quick Mode I1
    message is unacceptable because it uses a
    previously used Message ID 0xed39b62b (perhaps this is a duplicated packet)
    Oct 4 22:00:51 2006 Connection Refused -
    Policy violation UDP> on ixp0

    To me this points to a software issue, but linksys see's it as I'm not having enough bandwidth on the sites.. I'm like guys.. this is afte the sites have closed and everyone's gone home. The odds of this are rediculous, but even so.. your Dead Peer detection should re-establish the tunnel if it fails..
    I could see not having enough bandwidth caused repeated drops.. but they stay up solid till they fail and when they fail they're done.. reboot time

    sigh.. I don't know where to turn from here.. Does anyone have any ideas..
  3. rrevels

    rrevels Guest

    It's been quite some time since you posted this so I imagine you have it resolved now. However the symptoms are so similar to a problem I had that I thought I would go ahead and respond.

    I never figured out if the problem I had was hardware or software but I was using T-1s on both ends of the tunnel(s) and kept having the tunnels lock. One end, the end that would typically be thought of as the server side, would show connected while the other end would show "waiting for connection".

    When I originally set up the network I had two internet connections tied to the "server" side. When I tore down the redundant connection it just happened to be the one tied to the primary internet interface on the router. Since I could specify the interface to use for the tunnels I decided it didn't matter and left the primary open (no wire attached) and as the static address on the interface.

    Moving the remaining internet connection to the rv042 primary internet interface fixed the problem for me. There is also the possiblity that a surge was seen on the backup interface which partially damaged it and this is what caused the problem to go away when the cable was moved.

    In any case, I have two networks that run VPN tunnels with an rv042 on the "server" side. One uses rv042's in the field and the other uses sonic wall routers. Both function perfectly.

  4. Toxic

    Toxic Administrator Staff Member

    are you using Aggressive mode? I was lead to belive Aggressive mode is used to Software IPSec clients (Greenbow/SSH Sentinel etc) and not IPSec tunnels that are using VPN IPSec routers.
  5. tuxman

    tuxman Network Guru Member

    Unfortunetly that is not the case for me. I've tried with everything on, off and different encryption settings, doesn't seem to matter. I spent months working with Linksys support on this issue. Only to have them close my case twice, once granted was on my request becuause it sometimes takes more than the 120 hours before the issues return, the other one I was awaiting contact from a new support rep who was in a timezone so they could call me, and out of nowhere the case is closed. Everything points to a software issue. I'm not at all concerned with the fact the tunnel drops, my concern is that the tunnels hang in oposite connditions. With DPD enabled the session that says connected should reset itself after it doesn't see the other end, or atleast that's how I'm told it is supposed to work.

    Linksys kept comming back saying it's not firmware , it's bandwidth. Because they haddn't had any other complaints. Even my coversations with Cisco and several other CCNP's say that doesn't make any sense, bandwidth could cause the tunnels to drop, but not hang in oposite conditions.

    After the case was closed out of the blue, and after months of arguing with linksys I finally have had it. These devices are being removed and replaced with cisco 851's. Atleast with a cisco box I can actually troubleshoot a problem rather than looking at a log that tells me nothing on a website. Perhaps it was my fault for using a consumer based router for something that it is reported to support, but I feel that the linksys support team was not at all helpfull or at all interested in doing anything but trying to pin the issuee on something that doesen't make sense, and re focusing the issue away from them. They compare it to the RV082 and the RV016 as othere models that have the same features but they don't use the same firmware so that isn't a fair comparison. They also wouldn't even entertain the idea of swaping the devices with anything else they have that supported IPSEC Tunnels. Basically putting me in a position, where I have a problem that I can't fix, thus the decision to upgrade them get the rebate from Cisco and continue with a product that is proven in the market, and make a mental note of this mistake.
  6. Toxic

    Toxic Administrator Staff Member

    sorry to hear of your troubles. it does sound a very strange issues none the less. I hope the Cisco equipment will solve the issues for you.

Share This Page