VPN setup problems between AdTran and Cisco Pix firewalls

>Problem is, the tunnel just ain't there!
  Meaning Phase 1 (IKE) never completes?

Very important: after you added the Poland VPN settings to the PIX, did you re-apply the crypto map to the interface? Also good idea to clear the NAT table (in case you do get an IPSec SA built!):
  crypto map vpnmap interface outside
  clear xlate

  Are you absolutely, 100% positive your ike/isakmp keys match exactly on both the PIX & the Adtran?  And you're positive you don't have a typo in the ike/iskamp peer IPs?
  What specific PIX version are you running?  eg, 6.3(4) or what?  If 6.3(1), save the config & reboot the PIX - this particular version is very buggy & requires reboots to reset things after VPN or NAT changes.  Anything older than 6.3(4), I strongly suggest you upgrade to 6.3(5) if you have current SmartNet on it.

  On the PIX you have:
isakmp policy 20 group 1
  Does the Adtran default to group 1 or 2?  If 2, then just simply remove policy 20 - you can use the same policy for multiple VPN tunnels.

  On the Adtran for the HQ you have:
ip access-list extended VPN-10-vpn-selectors
  permit ip 192.168.0.0 0.0.255.255  192.168.1.0 0.0.0.255
# I'd suggest narrowing the above line to:
  permit ip 192.168.2.0 0.0.0.255  192.168.1.0 0.0.0.255  <- assuming the order of subnets is <local> <remote> like in a PIX crypto ACL.

  And I assume at the PIX location there isn't a 192.168.2.0/24 subnet anywhere behind the PIX that it's aware of?

cheers

Whew!  Had a server crash today.  Just got back to *this* problem...

Cisco pix version 6.3(5).  Keys match, I've typed them in twice.  Also checked (& checked...) th IPs, the peer IPs, the ip ranges, encryption/hash, the DH group, everything I could think of.  Yes, the link has to be Group 1 - the AdTran doesn't like anything else.

You are correct about the assumption, I even thought of it myself, and nothing in the ..2.0/24 subnet exists behind it.

I am rebooting both routers (things are quiet in Europe right now...) we'll see what happens...... . . .   .   .   .    .     .    .    .    .  . . . . ......
Nuttin', honey...

Anything else?  Dynamite?  Replacethe AdTran in Poland with a Cisco?

You didn't mention above - does Phase 1 ever complete? Or is it only Phase 2 that fails?

  Have you already tried narrowing the Adtran's crypto ACL?
ip access-list extended VPN-10-vpn-selectors
  permit ip 192.168.2.0 0.0.0.255  192.168.1.0 0.0.0.255  <-- already made more specific?

 I'd do the above on the Adtran, then flip-flop the order on your isakmp policies, so your PIX tries group 1 first, then re-apply crypto on the interface:
clear cry isa sa
isakmp policy 10 group 1
isakmp policy 20 group 2
crypto map vpnmap interface outside
isakmp enable outside

>Dynamite?  Replacethe AdTran in Poland with a Cisco?
   Hmm, maybe the latter.  But dynamite would be fun. ;)

Since you have nat-traversal disabled on the Adtran, I assume it's directly connected to the WAN link, w/ no NAT device in front of it?

cheers

Calvinetter:

What commands do I use to check on Phase 1/2 on the pix?  The AdTran isn't much help.  Their GUI just has up/down.  I changed the DH group to 2 on the Sweden<->Poland link, I can't fool around with the VPNs to HQ because I don't have OOB if something crashes and/or I lose contact with the far end!

sh cry isa sa   <-- shows status of all Phase 1 (IKE) SA's
sh cry ips sa   <-- shows status of Phase 2 (IPSec)

 You can also *temporarily* enable debugging for either Phase 1 or 2, while trying to establish a tunnel w/ Poland:
debug cry isak
   or
debug cry ips
  ** It's best to enable debugging only when traffic isn't too heavy (CPU hog).  
       When finished, it's faster to just turn off all debugging:
no debug all

<I can't fool around with the VPNs to HQ because I don't have OOB...
<I changed the DH group to 2 on the Sweden<->Poland link...
    Just to clarify on doing the "flip-flop" of the isakmp policy settings, ie:
isakmp policy 10 group 1
isakmp policy 20 group 2
    Note that "policy 10" isn't directly tied to your HQ VPN connection.  The '10' in "policy 10" is just a priority number - the PIX simply tries to use the settings in policy 10 first (lower # means higher priority), before trying policy 20 when doing an IKE negotiation.  Same goes for "crypto map vpnmap 10" -> the '10' is also just a priority number, & just helps you & the PIX keep things organized; the PIX won't purposely match up a "crypto map... 10" entry w/ an "isakmp policy 10" entry, it just starts with the higher priority entries first on both Phase 1 & 2.

cheers

calvinetter, the problem just got worse.  Last Friday I made some of the changes in the Pix but did NOT write them to memory, then rebooted the Pix (in Sweden).  The tunnel promptly fell over, and I have not been able to re-establish it.  Doing a "sh cry isa sa" on my end I can see that the router on the US end is trying to re-establish the tunnel, but something isn't quite right because it never establishes.  I had a guy in Sweden get into the router and send the running config to me in an e-mail, and darned if it doesn't look okay, nothing of importance has changed!  The Pix has been power-cycled AND "reload"ed, and yet nothing works properly any more.

Got any hints as to where to look, what to do?  I'd love to send *you* the configs so you can look at them (as opposed to putting them in a public forum like this one) so you can do a line-by-line comparison...

And I sure could use OOB right about now.  I'd even settle for 300 baud!

Bugger...  If you're *positive* nothing changed (permanently) on the PIX end, what about the router end? Anything at all changed on the router?  If IKE Phase 1 isn't even establishing, then some things to look for are:
- IP changes on either end
- isakmp policy changes on either end
- anything blocking UDP port 500 traffic between the router & PIX
- Has the isakmp key changed?  Even if it hasn't, sounds strange but sometimes deleting the isakmp key line for that peer, re-adding it, & disabling then re-enabling isakmp to the interface ("[no] isakmp enable outside" on the PIX) can sometimes fix it.

>configs so you can look at them (as opposed to putting them in a public forum like this one)...
  Next best thing is to post a sanitized (ie, passwords removed, public IPs masked like so: x.x.2.99, leave all subnet masks & private IPs intact) copy of the full configs for *both* sides (& a "sh ver" from the router) to:
     http://www.ee-stuff.com,
login with your usual EE username, click "Expert Area" tab, & upload the sanitized configs - use 22045960 as the Question ID.

>I'd even settle for 300 baud!
  Yeah even that would be something!

cheers

Calvinetter:

show crypto isakmp key command yields:

default              <customer>                       **************
                      <Poland>                      ***************
                      <Sweden>                     j3$h7&8$*^af+e9
purcell#

...so I delete and rebuild the isakmp key using the key above, and check for results:

purcell#sho cry isa sa
dst             src             state          conn-id slot status
<my ip>    <Poland ip>   QM_IDLE             51    0 ACTIVE
<my ip>    <Sweden ip>  MM_NO_STATE          0    0 ACTIVE (deleted)
<Sweden ip>  <my ip>    MM_NO_STATE          0    0 ACTIVE
<Sweden ip>  <my ip>    MM_NO_STATE          0    0 ACTIVE (deleted)

...and a minute later...

purcell#sho cry isa sa
dst             src             state          conn-id slot status
<my ip>    <Poland ip>    QM_IDLE             51    0 ACTIVE
<Sweden ip>  <my ip>    MM_NO_STATE          0    0 ACTIVE (deleted)

BTW - is the key randomly generated?  Is the key listed above in scrambled format, or is it the real key?

calvinetter:

Sorry for not answering the questions above.  Here goes...

> - IP changes on either end
> - isakmp policy changes on either end
> - anything blocking UDP port 500 traffic between the router & PIX
> - Has the isakmp key changed?

No to all of the above.  This is what's frustrating, NOTHING changed.  One minute it's working, the next minute (after a reboot) it doesn't.  Nothing that I was working with was touching the *primary* tunnel!  I went to great lengths and went out of my way (and with much trepidation) to leave that tunnel intact to avoid breaking it.

I can't believe that the tunnel is so fragile that it would fall over without the slightest provocation.  If I can, I'll have the Sweden end do as you suggested above.  Man, I miss OOB!

>show crypto isakmp key command yields...
>BTW - is the key randomly generated?  Is the key listed above in scrambled format, or is it the real key?
  It should show what the *actual* pre-shared key is (unscrambled), exactly as you'd originally typed it in when configuring it.

><Sweden ip>  <my ip>    MM_NO_STATE  0    0 ACTIVE (deleted)
   "MM_NO_STATE" tells you that it couldn't establish Phase 1 (IKE/isakmp).

Thanks for feedback on the questions...

>I can't believe that the tunnel is so fragile that it would fall over without the slightest provocation.
  I agree - not between a Cisco router & PIX! Typically it's absolutely rock solid, unless you're running buggy firmware on either or both devices, or there's some other network problem going on between the 2 peers.

cheers

Wow - that was a nasty, brutish problem:
1) changed the key on both ends.  Didn't work.
2) tore down the isakmp policy 20 in the Pix in Sweden.  Still no-go.
3) cleared the SA's on both ends.  Rebooted *both* routers. no-go.
4) put the isakmp policy 20 back in place. HOLY COW! it started working.  What the heck?!?!?!?
5) wrote the Pix config, did a reload, watched the tunnel come back up.  Whew!  I get to keep my job.

Well, it's 0330 and I'm now happy.  Maybe, just maybe, I can now get the Sweden <-> Poland link working.  I'm a little more battle-scarred but a lot more knowledgeable in VPN setups (well, between Cisco equipment, anyway)...

I'll be sure to keep you posted AND send you the configs when I get 'em working.

Ye gods, you did have a rough go of it!

>4) put the isakmp policy 20 back in place...
   We've never seen your HQ router config, but apparently it's configured for 'group 1' - that's the only difference between your 2 isakmp policies on the PIX.   Remember: both IPSec peers must find a set of isakmp & ipsec parameters that they can agree on - if there isn't an exactly matching set of parameters in one policy or another, they will *not* be able to form SA's.  Parameters include: authentication type (eg, pre-shared key), encryption (3DES, AES, etc), hash algorithm (MD5 or SHA), DH group (usually '1' or '2'), & SA lifetime if explicitly set.

>Whew!  I get to keep my job.
   ;)

cheers

calvinetter:

I'm not sure the AdTran is even attempting to establish the tunnel.  Heres the debug output from the Sweden Pix:

VPN Peer: IPSEC: Peer ip:{HQ ip addx}/500 Decrementing Ref cnt to:2 Total VPN Peers:1
VPN Peer: IPSEC: Peer ip:{HQ ip addx}/500 Decrementing Ref cnt to:1 Total VPN Peers:1
ISAKMP (0): beginning Quick Mode exchange, M-ID of 2060249858:7acceb02
crypto_isakmp_process_block:src:{HQ ip addx}, dest:{Sweden ip addx} spt:500 dpt:500
OAK_QM exchange
oakley_process_quick_mode:
OAK_QM_IDLE
ISAKMP (0): processing SA payload. message ID = 2060249858

ISAKMP : Checking IPSec proposal 1

ISAKMP: transform 1, ESP_3DES
ISAKMP:   attributes in transform:
ISAKMP:      encaps is 1
ISAKMP:      SA life type in seconds
ISAKMP:      SA life duration (basic) of 28800
ISAKMP:      SA life type in kilobytes
ISAKMP:      SA life duration (VPI) of  0x0 0x46 0x50 0x0
ISAKMP:      authenticator is HMAC-MD5
ISAKMP (0): atts are acceptable.
ISAKMP (0): processing NONCE payload. message ID = 2060249858

ISAKMP (0): processing ID payload. message ID = 2060249858
ISAKMP (0): processing ID payload. message ID = 2060249858
ISAKMP (0): processing NOTIFY payload 24576 protocol 3
        spi 1053531748, message ID = 2060249858
ISAKMP (0): processing responder lifetime
ISAKMP (0): responder lifetime of 3600s
ISAKMP (0): Creating IPSec SAs
        inbound SA from    {HQ ip addx} to  {Sweden ip addx} (proxy     192.168.1.0 to     192.168.3.0)
        has spi 352778341 and conn_id 3 and flags 4
        lifetime of 3600 seconds
        lifetime of 4608000 kilobytes
        outbound SA from  {Sweden ip addx} to    {HQ ip addx} (proxy     192.168.3.0 to     192.168.1.0)
        has spi 1053531748 and conn_id 4 and flags 4
        lifetime of 3600 seconds
        lifetime of 4608000 kilobytes
VPN Peer: IPSEC: Peer ip:{HQ ip addx}/500 Ref cnt incremented to:2 Total VPN Peers:1
VPN Peer: IPSEC: Peer ip:{HQ ip addx}/500 Ref cnt incremented to:3 Total VPN Peers:1
return status is IKMP_NO_ERROR
Sweden#

NOTHING from the AdTran in Poland.  Should one end or both ends try initiating the tunnel?  If only one, *which* one?  The end that tries sending packets first?

The "reaper" on the Pix end only tests for the tunnel to HQ, and the AdTran doe an "R U THERE" query.  nowhere do I see them trying to negotiate between each other on the IKE level.

Do you need more config snippets to help you?

Either end should be able to initiate the tunnel.  You'll want to send traffic from a host at 1 site to an internal host at the other remote site to try & initiate the VPN.  You could start a continous ping from a PC at Sweden to a host at the Poland LAN, then see if anything's happening at w/ Phase 1:
  sh cry isak sa
  debug cry isak

It would be best if you posted full but "sanitized" configs (passwords removed, public IPs masked like so: x.x.23.4) for both the Adtran & the Sweden PIX to:  www.ee-stuff.com
    Just login w/ your usual EE username, click "Expert Area", choose "Upload a new file", then use 22045960 as the Question ID.  To conserve space on this page, I'd suggest uploading a separate file with the output of "sh cry isak sa" & "debug cry isak" after you've sent traffic from a PC at both sites to the other.

  Maybe lrmoore can help with the Adtran side: he's had experience w/ Netvantas, maybe also w/ VPN configs.  After you post to www.ee-stuff.com, I'd suggest making a 20-pt "pointer question", also in the Firewalls TA, with the URL for this question in the body of the post.

cheers

Done.  Have fun reading my mishmash of configs, and remember that I inherited this problem and didn't do the original setup(s).  Ya gotta work with what you're handed...

I'll keep carefully poking it to see if I can tweak it into working, but I'm now gun-shy and am trying to avoid major crashes like last week.  Can you blame me?

D'oh! Now I've got homework to do...  I'll take a peek sometime this weekend.  Once bit & twice shy, eh?  Don't blame you at all!

cheers

 Glad we finally had a chance to see the configs...
  Your PIX is missing a line in your nonat ACL, run this:

access-list nonat permit ip 192.168.3.0 255.255.255.0 192.168.2.0 255.255.255.0
clear xlate
crypto map vpnmap interface outside

  Is the PIX or the Adtran behind any NAT device (ie a router, firewall or other layer-3 device)?  Seems like they aren't since you don't have "isakmp nat-traversal" anywhere in the PIX config & you've got "nat-traversal v1/v2 disable" on the Adtran, but wanted to confirm, since this is important!
  Even if they aren't I highly recommend enabling nat-traversal on both the PIX & the Adtran, since nat-traversal is a good thing.  Looks like the Adtran will let you enable it on specific IKE policies.  So you could do this:
   PIX:
no isakmp enable outside
isakmp nat-t
isakmp enable outside
crypto map vpnmap interface outside

   Adtran:
crypto ike policy 110
  nat-traversal v1 enable
  nat-traversal v2 enable
( On the Adtran, do whatever's necessary to ensure your IKE changes take effect. )

  FYI - If the PIX is *not* behind another firewall or firewall-capable router, then you'll want to remove the wide-open 'outbound' ACL!  Replace it with a "safe" rule (& use a name that makes sense):
no access-list outbound
access-list inbound permit icmp any any  <- allows outbound pings & traceroute to work
access-group inbound in interface outside

  On the Adtran:
>crypto ike policy 110
  >respond anymode    <- did you try forcing 'main' mode?
  >local-id address {Poland ip addx}  <- Just to confirm this is the Adtran's WAN IP, right? (It should be.)

cheers

We're close!  As soon as I put the ACL in, the tunnel came up!  I was thinking about this problem Friday, and looking over the configs when it was quiet I wondered if an acl was missing.  Good to know my hunch was scorrect.  NOT that I yet understand acl's...

Routing still not working:

Sweden# ping 192.168.2.1
        192.168.2.1 NO response received -- 1000ms
        192.168.2.1 NO response received -- 1000ms
        192.168.2.1 NO response received -- 1000ms
Sweden# ping 192.168.2.2
        192.168.2.2 NO response received -- 1000ms
        192.168.2.2 NO response received -- 1000ms
        192.168.2.2 NO response received -- 1000ms
Sweden#

...and...


Poland>ping 192.168.3.2
Type CTRL+C to abort.
Legend: '!' = Success, '?' = Unknown host, '$' = Invalid host address
        '*' = Request timed out, '-' = Destination host unreachable
        'x' = TTL expired in transit

Sending 5, 100-byte ICMP Echos to 192.168.3.2, timeout is 2 seconds:

-----
Success rate is 0 percent (0/5)
Poland>


So the problem is now down to routing and acl's??

But wait!  doing a sh cry ips sa on both ends yields:

Sweden# sh cry ips sa
interface: outside
    Crypto map tag: vpnmap, local addr. {Sweden ip addx}

   local  ident (addr/mask/prot/port): (192.168.3.0/255.255.255.0/1/0)
   remote ident (addr/mask/prot/port): (192.168.2.0/255.255.255.0/1/0)
   current_peer: {Poland ip addx}:0
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: {Sweden ip addx}, remote crypto endpt.: {Poland ip addx}
     path mtu 1500, ipsec overhead 0, media mtu 1500
     current outbound spi: 0

     inbound esp sas:

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:

     outbound ah sas:

     outbound pcp sas:

   local  ident (addr/mask/prot/port): (192.168.3.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (192.168.2.0/255.255.255.0/0/0)
   current_peer: {Poland ip addx}:0
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: {Sweden ip addx}, remote crypto endpt.: {Poland ip addx}
     path mtu 1500, ipsec overhead 0, media mtu 1500
     current outbound spi: 0

     inbound esp sas:

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:

     outbound ah sas:

     outbound pcp sas:

   local  ident (addr/mask/prot/port): (192.168.3.0/255.255.255.0/1/0)
   remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/1/0)
   current_peer: {HQ ip addx}:0
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: {Sweden ip addx}, remote crypto endpt.: {Hq ip addx}
     path mtu 1500, ipsec overhead 0, media mtu 1500
     current outbound spi: 0

     inbound esp sas:

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:

     outbound ah sas:

     outbound pcp sas:

   local  ident (addr/mask/prot/port): (192.168.3.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
   current_peer: {HQ ip addx}:500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 2184, #pkts encrypt: 2184, #pkts digest 2184
    #pkts decaps: 2303, #pkts decrypt: 2309, #pkts verify 2309
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
    #send errors 1, #recv errors 0

     local crypto endpt.: {Sweden ip addx}, remote crypto endpt.: {HQ ip addx}
     path mtu 1500, ipsec overhead 56, media mtu 1500
     current outbound spi: 9df412fd

     inbound esp sas:
      spi: 0x23b9f614(599389716)
        transform: esp-3des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 4, crypto map: vpnmap
        sa timing: remaining key lifetime (k/sec): (4607777/2417)
        IV size: 8 bytes
        replay detection support: Y

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x9df412fd(2650018557)
        transform: esp-3des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 3, crypto map: vpnmap
        sa timing: remaining key lifetime (k/sec): (4607766/2416)
        IV size: 8 bytes
        replay detection support: Y

     outbound ah sas:

     outbound pcp sas:

Sweden#

...and...

Poland#sh cry ips sa
IPSec Security Associations: Total IPSec SAs: 2

  Peer IP Address: {Poland ip addx}
  Direction: Inbound
  SPI: 0xDB81236C (3682673516)
  Encapsulation: ESP
  RX Bytes: 30306553
  Selectors: Src:192.168.1.0/255.255.255.0  Port:ANY  Proto:ALL IP
             Dst:192.168.2.0/255.255.255.0  Port:ANY  Proto:ALL IP
  Hard Lifetime: 2820
  Soft Lifetime: 0
  Crypto Map: VPN 10

  Peer IP Address: {HQ ip addx}
  Direction: Outbound
  SPI: 0x5129B638 (1361688120)
  Encapsulation: ESP
  TX Bytes: 839076
  Selectors: Src:192.168.2.0/255.255.255.0  Port:ANY  Proto:ALL IP
             Dst:192.168.1.0/255.255.255.0  Port:ANY  Proto:ALL IP
  Hard Lifetime: 2820
  Soft Lifetime: 2790
  Crypto Map: VPN 10

Poland#


To answer your question, the Poland AND the Sweden routers are *directly* connected to the Internet.  They are not "behind" anything but the CSU/DSU...

And I'm still gun-shy.  Is the "no isakmp enable outside" going to kill the Sweden link again?

yes, the Adtran's WAN IP is correct.  I keep checking it just to make sure I didn't fat-finger it...

So close.......

>Sweden# ping 192.168.2.1
  You absolutely, positively should ping from a *workstation/server* (at either site) to a PC or server at the other site, & not between the PIX & the Adtran! Pinging directly from the PIX (or Adtran I'll bet), traffic is going to be sent out to its default gateway from the outside interface, & since that pattern doesn't match the crypto ACLs, it's not going to be considered traffic that needs to be wrapped in a VPN tunnel (besides, traffic sent to private IPs will only die at your ISP anyway).
  Notice the fact that you're not getting any packets encrypted/decrypted on the Adtran link:
> ...current_peer: {Poland ip addx}
> #pkts encaps: 0, #pkts encrypt: 0,
> #pkts decaps: 0, #pkts decrypt: 0,

> Poland#sh cry ips sa
> IPSec Security Associations: Total IPSec SAs: 2
   Strange - on the Adtran there are 2 SA's, but both seem to be simply the tunnel between Poland & HQ; I only see 192.168.1.x & 192.168.2.x, & "Crypto Map: VPN 10" - there's nothing referencing the PIX, & yet the PIX shows it has an SA with Poland? Are we missing output from the Adtran?

>Poland AND the Sweden routers are *directly* connected to the Internet.
  Thanks, just had to confirm!

>And I'm still gun-shy.  Is the "no isakmp enable outside" going to kill the Sweden link again?
   It'll only dump any current IKE/isakmp SA's, but they should re-establish as needed - just send traffic between hosts at either site & the tunnel will re-establish.  Disabling/re-enabling iskamp on the interface forces the PIX to apply any changes to isakmp, though you can usually accomplish this by re-applying the crypto map to the interface, which also causes current SA's to be dumped.  At a minimum, you should re-apply the crypto map to the interface whenever you make changes to VPN settings.

cheers

Well... I just tried pings from Poland to Sweden and vice-versa:
(Poland server at 192.168.2.2, Sweden server at 192.168.3.2)

Here's the Poland server:

Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

C:\Documents and Settings\administrator.MyDomain>ping 192.168.3.2

Pinging 192.168.3.2 with 32 bytes of data:

Reply from 192.168.3.2: bytes=32 time=71ms TTL=127
Reply from 192.168.3.2: bytes=32 time=69ms TTL=127
Reply from 192.168.3.2: bytes=32 time=68ms TTL=127
Reply from 192.168.3.2: bytes=32 time=67ms TTL=127

Ping statistics for 192.168.3.2:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 67ms, Maximum = 71ms, Average = 68ms

C:\Documents and Settings\administrator.MyDomain>


Here's the Sweden server:

Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

C:\Documents and Settings\administrator.MyDomain>ping 192.168.2.2

Pinging 192.168.2.2 with 32 bytes of data:

Reply from 192.168.2.2: bytes=32 time=72ms TTL=128
Reply from 192.168.2.2: bytes=32 time=70ms TTL=128
Reply from 192.168.2.2: bytes=32 time=67ms TTL=128
Reply from 192.168.2.2: bytes=32 time=67ms TTL=128

Ping statistics for 192.168.2.2:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 67ms, Maximum = 72ms, Average = 69ms

C:\Documents and Settings\administrator.MyDomain>


Inless I've gone insane (a very REAL possibility!), 60-70ms response time means that the packets are staying within the EU BGP area(s) and not traversing the Internet to the US (and back)!  Pings from me here in Washington State show times of 225ms to either server, so I *think* that's a valid statement...

SO, the question is - leave everything alone, write the configs, cross my fingers and reboot?
Make the additional changes you suggested, test, and do the above?

Man, I'm *really* paranoid until I can get the OOB working...

But I think the tunnels are working and that's a HUGE improvement!

Lemme know Yer Perfessional Opeenyun, and we'll call it a successful troubleshoot!