DComTalk.com

Mike Drechsler - SPAM PRO · Guest

Vince wrote:

Vince · Guest

Hi Mike,

OK, I tried setting up the IKE profiles as you suggested. I have one
IKE profile for each tunnel on each router - the ends of each tunnel
have identical IKE profile settings. Both tunnels coming from Site C
are fine, communication is good, no excessive phase 2 renegotiations.
The problem now is that the tunnels between site A and B were still
re-negotiating phase 2 every few seconds, and periodically lose
communication between the subnets until I re-set the tunnel. I just
now tried changing the advanced IKE settings to use old SA's until
expired instead of using new SA's immediately, that seems to have
quieted things down for now - but for how long, who knows. Any
suggestions?

Mike Drechsler - SPAM PRO · Guest

Vince wrote:

Vince · Guest

Not sure I understand what you mean by different - each router has 2
tunnels, and each tunnel has the same IKE profile on each end, but each
pair has a unique profile/password/key, shared between the 2 routers at
each end. Shouldn't the parameters at each end be the same? Or does
each and every password need to be unique?

Here's what I have now:

Site A <==Tunnel A-B==> Site B
Router A config for "Tunnel A-B":(IKE Profile: "A-B", password: "a2b")
Router B config for "Tunnel A-B":(IKE Profile: "A-B", password: "a2b")

Site A <==Tunnel A-C==> Site C
Router A config for "Tunnel A-C":(IKE Profile: "A-C", password: "a2c")
Router C config for "Tunnel A-C":(IKE Profile: "A-C", password: "a2c")

Site B <==Tunnel A-B==> Site C
Router B config for "Tunnel B-C":(IKE Profile: "B-C", password: "b2c")
Router C config for "Tunnel B-C":(IKE Profile: "B-C", password: "b2c")

Vince · Guest

Sorry, the last tunnel should be:
Site B <==Tunnel B-C==> Site C
Router B config for "Tunnel B-C":(IKE Profile: "B-C", password: "b2c")
Router C config for "Tunnel B-C":(IKE Profile: "B-C", password: "b2c")

Could there be an issue with the way I am "nailing" the tunnels?
Should only on side have a "dead peer detection" and/or 24-hour
scheduled connection and/or 0-value timeout for the tunnel?

Mike Drechsler - SPAM PRO · Guest

Vince wrote:
[quote]Sorry, the last tunnel should be:
Site B <==Tunnel B-C==> Site C
Router B config for "Tunnel B-C":(IKE Profile: "B-C", password: "b2c")
Router C config for "Tunnel B-C":(IKE Profile: "B-C", password: "b2c")

Could there be an issue with the way I am "nailing" the tunnels?
Should only on side have a "dead peer detection" and/or 24-hour
scheduled connection and/or 0-value timeout for the tunnel?
[/quote]
Dead peer detection is a bit hit or miss. I start with it disabled and
then add it in if the connection seems unstable. It only helps if the
underlying network has problems though. (ADSL link that goes offline,
occasional packetloss, that kind of thing). If you see constant dead
peer detected messages in the logs you may try turning it off. If the
connection is stable with it disabled then either the dead peer
detection settings were wrong or something wasn't responding to
keepalive messages as expected.

Scheduled connections do nothing for IPSec. This is for PPP style
connections.

Setting the idle to 0 is the correct way to indicate the tunnel should
stay "nailed" up at all times regardless of traffic.

So are your tunnels still renegotiating every few seconds? Have you had
any luck isolating the problem? The last mention you said that both
tunnels from one site were working properly but the connection between
two other sites were still not working. Have you deleted the tunnels
between those two problem sites and tried creating all new settings?
Have you tried calling Netopia to have them look at the problem?

--
WARNING! Email address has been altered for spam resistance.
Please remove the -deletethispart-. section before replying directly.
Mike Drechsler (mike-newsgroup@-deletethispart-.upcraft.com)

Vince · Guest

The persistent re-negotiation between the 2 problem sites seems to take
place when either phase1 or phase 2 has expired (I haven't been able to
accurately determine determine the timing, since the expiration
happens when I'm at work and I can't make a VPN like my client's
network).

I'll try removing the scheduled connections (for IPSec) and the dead
peer connections. I did delete and re-create the tunnels once after I
created all new IKE profiles, but I'll try it again.

Any advice on timing/duration settings of phase1/2 configs? Should
phase1 be set to expire after 24hrs and phase 2 set for something like
8 or 12 hrs?

Vince · Guest

Well Mike, I thought I was OK, but I'm still having trouble.

I re-created the tunnels between the 2 problem endpoints (Sites A and
B), and things seemed to work nicely. Phase 2 re-negotiations took
only a handful of attempts. For the past 5 days or so, the tunnels
have been stable, with the phase 2's renegotiating successfully as
scheduled (every 4 hours.) Then just this morning, I ran into the same
problem again with the A-B tunnel, with phase 2 failing repeatedly
(endless "Phase 2 complete" messages) for several hours. I rebooted
the router at Site B and the tunnels re-established after about 90
seconds. Connections and IP traffic between sites A and B have been
fine for the past 3 hours; hopefully the next phase 2 re-negotiation
won't barf.

I'm at my wits end with this. The tunnels out of Site C have been
rock-solid since inception. The A-B tunnel settings at Sites A and B
are identical (and different from the A-C and B-C settings). I have
done a 'show config' dump and checked everything line by line.
Furthermore, the IKE and Connection Profile settings for the A-B tunnel
match the A-C and B-C settings (though unique from the other 2 tunnels
in name, IKE Profile, and password).

Netopia online chat help would not offer any VPN configuration
assistance; they referred me to their fee-based production support
offerings (consistent with their website's advertised support policy
regarding VPN's).

The only common issue I can think of at this point is that Sites A and
B both have an ISP connection requiring PPPOE underlying encapsulation
even though they have fixed IP addresses. Site C (the oldest) for some
reason, even though under the same provider (SBC), does not utilize
PPPOE at all.

Any thoughts?

Mike Drechsler - SPAM PRO · Guest

Vince wrote:

Vince · Guest

I think I will be calling Netopia this week or next. This is
maddening. Sometimes the Phase 2 IPSec renegotiation (at time of
expiration) takes 2 minutes, sometimes it takes 2 hours, sometimes it
never succeeds until I bounce the routers. This problem is now
occurring in all 3 locations. I am going to do a factory reset on all
3 routers this week and try re-building the setups from scratch, but at
this point I have my doubts that even that will work.

Even after scouring the 'net, I was unable to find anyone having a
similar problem, so woe is me.

If anyone has seen this type of behavior, and could offer any insight,
I would greatly appreciate it. I will post my results from the rebuild
and Netopia supposrt assistance as I have them.

Mike Drechsler - SPAM PRO · Guest

Vince wrote:

Vince · Guest

Boy, if that's the case, I would be ecstatic if I can get this
resolved. OK, say the scenario you described is applicable in my case.
How would I best explain this to my ADSL provider (SBC) to convince
them of an actual problem that falls within the scope of their service
guarantees? I'm worried that the conversation will end with "Well, you
can surf the internet, right? Then it's working as it shoud."

Mike Drechsler - SPAM PRO · Guest

Vince wrote:

Vince · Guest

OK, during a period where the Phase 2's just thrashing each other from
both ends (central office and problem remote office), I tried ping
testing to a public address (easynews.com), the local DNS Server, and
the remote router's WAN IP address, all with no packet loss from either
side after about 2-3 minutes of continuous pings at min and max packet
sizes.

I've gotten to the point where I have pushed the Phase 1 timeout to
24hrs and the Phase 2 timeout to 12hrs, just to keep my clients from
major downtime. That only worked for a day and a half. Yet again, the
remote office had to hard-boot the router and wait 5 minutes before the
tunnel was restored.

I have come across 2 spare Linksys BEFVP41's which I am about to try,
just for comparison. If they appear to work better, I will most likely
junk the Netopias. If the problems remain the same, I may just nuke
the site for morbid. This has been unbelievably frustrating.

Mike Drechsler - SPAM PRO · Guest

Vince wrote:

3-site VPN implementation w/Terminal Server Goto page Previous 1, 2

	DComTalk.com Forum Index -> VPN	All times are GMT Goto page Previous 1, 2
Page 2 of 2