Solved

VPN setup problems between AdTran and Cisco Pix firewalls

Posted on 2006-11-01
21
2,258 Views
Last Modified: 2013-11-16
I have a Cisco 515e Pix in my Sweden office, an Adtran NetVanta 1224R in the Poland office, and a Cisco 2821 router (with firewall and VPN capabilities, IOS ver 12.4(3) ) at HQ.  I have two VPN tunnels established already: one between The HQ router (the 2821) and the Cisco Pix in Sweden, and one between the HQ router and the AdTran NetVanta in Poland. They work just fine.

Life is good as long as I don't try to get packets from Sweden to Poland and/or back again.  The internal IP ranges are 192.168.1.0/24 for the home office, 192.168.2.0/24 for Poland, and 192.168.3.0/24 for Sweden.  I *don't* want to route traffic between Sweden and Poland via our tunnels to the HQ building, I want them to go directly (via another VPN tunnel) without traversing the links to HQ and back!

I have tried setting up the VPN tunnel between Poland/Sweden, but it refuses to come up.  Here are some code snippets.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In the Pix:
sysopt connection permit-ipsec
crypto ipsec transform-set myset esp-3des esp-md5-hmac
crypto map vpnmap 10 ipsec-isakmp
crypto map vpnmap 10 match address hq-acl
crypto map vpnmap 10 set peer 64.128.84.14
crypto map vpnmap 10 set transform-set myset
crypto map vpnmap 20 ipsec-isakmp
crypto map vpnmap 20 match address poland-acl
crypto map vpnmap 20 set peer 80.244.136.74
crypto map vpnmap 20 set transform-set myset
crypto map vpnmap interface outside
isakmp enable outside
isakmp key ******** address a.b.c.d netmask 255.255.255.255
isakmp key ******** address w.x.y.z netmask 255.255.255.255
isakmp identity address
isakmp keepalive 10
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption 3des
isakmp policy 10 hash md5
isakmp policy 10 group 2
isakmp policy 10 lifetime 86400
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption 3des
isakmp policy 20 hash md5
isakmp policy 20 group 1
isakmp policy 20 lifetime 86400

access-list hq-acl permit ip 192.168.3.0 255.255.255.0 192.168.1.0 255.255.255.0
access-list hq-acl permit icmp 192.168.3.0 255.255.255.0 192.168.1.0 255.255.255.0
access-list poland-acl permit ip 192.168.3.0 255.255.255.0 192.168.2.0 255.255.255.0
access-list poland-acl permit icmp 192.168.3.0 255.255.255.0 192.168.2.0 255.255.255.0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In the AdTran:
ip crypto
!
crypto ike policy 100
  initiate main
  respond anymode
  local-id address 80.244.136.74
  nat-traversal v1 disable
  nat-traversal v2 disable
  peer 64.128.84.14
  attribute 1
    encryption 3des
    hash md5
    authentication pre-share
    lifetime 86400
!
crypto ike policy 110
  initiate main
  respond anymode
  local-id address 80.244.136.74
  nat-traversal v1 disable
  nat-traversal v2 disable
  peer 213.115.82.166
  attribute 1
    encryption 3des
    hash md5
    authentication pre-share
    lifetime 86400
!
crypto ike remote-id address a.b.c.d preshared-key ************ ike-policy 100 crypto map VPN 10 no-mode-config no-xauth
crypto ike remote-id address w.x.y.z preshared-key ************ ike-policy 110 crypto map VPN 20 no-mode-config no-xauth nat-t v1 disable nat-t v2 disable
!
crypto ipsec transform-set esp-3des-esp-md5-hmac esp-3des esp-md5-hmac
  mode tunnel
!
crypto map VPN 10 ipsec-ike
  description HQ
  match address VPN-10-vpn-selectors
  set peer 64.128.84.14
  set transform-set esp-3des-esp-md5-hmac
  ike-policy 100
crypto map VPN 20 ipsec-ike
  description Sweden_office
  match address VPN-20-vpn-selectors
  set peer 213.115.82.166
  set transform-set esp-3des-esp-md5-hmac
  ike-policy 110

!
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
!
ip access-list extended VPN-20-vpn-selectors
  permit ip 192.168.2.0 0.0.0.255  192.168.3.0 0.0.0.255
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I've gone over the passwword settings and IP addresses, and IKE, Hash, and DH a million times, it all looks good.  Problem is, the tunnel just ain't there!

Any ideas?  Need more code snippets?

(My head hurts from banging it against the desk too many times)
0
Comment
Question by:Linette_Laiminger
  • 11
  • 10
21 Comments
 
LVL 20

Expert Comment

by:calvinetter
Comment Utility
>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
0
 

Author Comment

by:Linette_Laiminger
Comment Utility
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?

0
 
LVL 20

Expert Comment

by:calvinetter
Comment Utility
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
0
 

Author Comment

by:Linette_Laiminger
Comment Utility
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!
0
 
LVL 20

Expert Comment

by:calvinetter
Comment Utility
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
0
 

Author Comment

by:Linette_Laiminger
Comment Utility
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!
0
 
LVL 20

Expert Comment

by:calvinetter
Comment Utility
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
0
 

Author Comment

by:Linette_Laiminger
Comment Utility
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?
0
 

Author Comment

by:Linette_Laiminger
Comment Utility
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!
0
 
LVL 20

Expert Comment

by:calvinetter
Comment Utility
>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
0
How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

 

Author Comment

by:Linette_Laiminger
Comment Utility
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.
0
 
LVL 20

Expert Comment

by:calvinetter
Comment Utility
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
0
 

Author Comment

by:Linette_Laiminger
Comment Utility
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?
0
 
LVL 20

Expert Comment

by:calvinetter
Comment Utility
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
0
 

Author Comment

by:Linette_Laiminger
Comment Utility
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?
0
 
LVL 20

Expert Comment

by:calvinetter
Comment Utility
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
0
 
LVL 20

Expert Comment

by:calvinetter
Comment Utility
 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
0
 

Author Comment

by:Linette_Laiminger
Comment Utility
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.......

0
 
LVL 20

Expert Comment

by:calvinetter
Comment Utility
>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
0
 

Author Comment

by:Linette_Laiminger
Comment Utility
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!
0
 
LVL 20

Accepted Solution

by:
calvinetter earned 500 total points
Comment Utility
>Lemme know Yer Perfessional Opeenyun,
  LOL!  Ok, I'll trah 'n tell ya wha' a thunk about...

>leave everything alone, write the configs, cross my fingers and reboot?
  Yes!  "If it ain't broke, don't fix it."
Finally! Confirmed we're able to send traffic between both remote LANs?!  If that's the case, leave AS IS, save configs & go have a well-deserved drink.  "frozen or on the rocks?"

>Inless I've gone insane (a very REAL possibility!), 60-70ms response time...
    ...is entirely expected.  Remember - this is a site-to-site VPN tunnel, built between 2 EU sites.  This traffic wouldn't need to traverse halfway around the world unless there's a HUGE continental outtage, say 99.9% of EU is down?  "Oops, I cut the fiber...um, all of it!"

Whew, I think I'll have a drink as well.
cheers!
0

Featured Post

6 Surprising Benefits of Threat Intelligence

All sorts of threat intelligence is available on the web. Intelligence you can learn from, and use to anticipate and prepare for future attacks.

Join & Write a Comment

Suggested Solutions

This article assumes you have at least one Cisco ASA or PIX configured with working internet and a non-dynamic, public, address on the outside interface. If you need instructions on how to enable your device for internet, or basic configuration info…
To setup a SonicWALL for policy based routing to be used with the Websense Content Gateway there are several steps that need to be completed. Below is a rough guide for accomplishing this. One thing of note is this guide is intended to assist in the…
Illustrator's Shape Builder tool will let you combine shapes visually and interactively. This video shows the Mac version, but the tool works the same way in Windows. To follow along with this video, you can draw your own shapes or download the file…
This video shows how to remove a single email address from the Outlook 2010 Auto Suggestion memory. NOTE: For Outlook 2016 and 2013 perform the exact same steps. Open a new email: Click the New email button in Outlook. Start typing the address: …

728 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now