cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3866
Views
0
Helpful
24
Replies

Site to Site VPN with ASA 5520 *please help*

jmmeisner
Level 1
Level 1

I'm using two ASA 5520's and trying to set up a site-to-site VPN.  This looks to be fairly simple, but I'm on my third day of trying to get this up and running. Both 5520's are running the latest IOS 9.1(5).

Please note: I've substituted [#1-WAN IP] and [#2-WAN IP] for the ASA's WAN IP addresses.

Thanks in advance for any help you might have.

-------------------------------------------------------------------------------------------------------------------------------------------------

ASA 5520 # 1:

crypto ikev1 enable outside

object network net-local
subnet 10.0.0.0 255.255.255.0
 

object network net-remote
subnet 172.20.0.0 255.255.255.0
 

access-list outside_1_cryptomap permit ip object net-local object net-remote

tunnel-group [#2-WAN IP] type ipsec-l2l

tunnel-group [#2-WAN IP] ipsec-attributes
pre-shared-key cisco123
 

crypto ikev1 policy 10 
authentication pre-share
encrypt 3des
hash sha
group 2
lifetime 86400
 

crypto ipsec ikev1 transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

crypto map oustide_map 1 match address outside_1_cryptomap
crypto map oustide_map 1 set ikev1 transform-set ESP-3DES-SHA
crypto map outside_map 1 set pfs group1
crypto map outside_map 1 set peer [#2-WAN IP]
crypto map outside_map interface outside

nat (inside,outside) 1 source static net-local net-local destination static net-remote net-remote

 

-------------------------------------------------------------------------------------------------------------------------------------------------


ASA 5520 #2:

crypto ikev1 enable outside

object network net-local
subnet 172.20.0.0 255.255.255.0
 

object network net-remote
subnet 10.0.0.0 255.255.255.0
 

access-list outside_1_cryptomap permit ip object net-local object net-remote

tunnel-group [#1-WAN IP] type ipsec-l2l

tunnel-group [#1-WAN IP] ipsec-attributes
pre-shared-key cisco123
 

crypto ikev1 policy 10 
authentication pre-share
encrypt 3des
hash sha
group 2
lifetime 86400
 

crypto ipsec ikev1 transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

crypto map oustide_map 1 match address outside_1_cryptomap
crypto map oustide_map 1 set ikev1 transform-set ESP-3DES-SHA
crypto map outside_map 1 set pfs group1
crypto map outside_map 1 set peer [#1-WAN IP]
crypto map outside_map interface outside

nat (inside,outside) 1 source static net-local net-local destination static net-remote net-remote

 

24 Replies 24

DTI-EQ# sh activation-key | i 3DES
Encryption-3DES-AES               : Enabled        perpetual
DTI-EQ#

 

DTI-HQ# sh activation-key | i 3DES
Encryption-3DES-AES               : Enabled        perpetual
DTI-HQ#

 

Can you run that packet-tracer once again with the "detailed" keyword? (You might want to "undebug all" first.)

Making some progress. The tunnel looks to be up!

Strange thing now, from the HQ side, I can not reach a shared folder on the EQ side.

I can on the other hand, reach a shared folder on the HQ from the EQ side.

 

Pings aren't going through either way from computers on each side's network.

 

Do I need to have an access list for icmp for the ping to respond?

 

--

 

DTI-HQ# sh crypto isa sa

IKEv1 SAs:

   Active SA: 1
    Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1   IKE Peer: 66.23.138.230
    Type    : L2L             Role    : initiator
    Rekey   : no              State   : MM_ACTIVE

There are no IKEv2 SAs
DTI-HQ# sh crypto ipsec sa
interface: outside
    Crypto map tag: outside_map, seq num: 1, local addr: 50.246.85.10

      access-list outside_1_cryptomap extended permit ip 10.0.0.0 255.255.255.0 172.20.0.0 255.255.255.0
      local ident (addr/mask/prot/port): (10.0.0.0/255.255.255.0/0/0)
      remote ident (addr/mask/prot/port): (172.20.0.0/255.255.255.0/0/0)
      current_peer: 66.23.138.230


      #pkts encaps: 56, #pkts encrypt: 56, #pkts digest: 56
      #pkts decaps: 51, #pkts decrypt: 51, #pkts verify: 51
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 56, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #TFC rcvd: 0, #TFC sent: 0
      #Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
      #send errors: 0, #recv errors: 0

      local crypto endpt.: 50.246.85.10/0, remote crypto endpt.: 66.23.138.230/0
      path mtu 1500, ipsec overhead 58(36), media mtu 1500
      PMTU time remaining (sec): 0, DF policy: copy-df
      ICMP error validation: disabled, TFC packets: disabled
      current outbound spi: 59F3E112
      current inbound spi : E333B239

    inbound esp sas:
      spi: 0xE333B239 (3811815993)
         transform: esp-3des esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 1, IKEv1, }
         slot: 0, conn_id: 4096, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (3914991/28313)
         IV size: 8 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x000FFFFF 0xFFFFFFFF
    outbound esp sas:
      spi: 0x59F3E112 (1509155090)
         transform: esp-3des esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 1, IKEv1, }
         slot: 0, conn_id: 4096, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (3914992/28313)
         IV size: 8 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001

DTI-HQ#

 

DTI-HQ# packet-tracer input inside tcp 10.0.0.41 1024 172.20.0.41 23

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,outside) source static net-local net-local destination static net-remote net-remote
Additional Information:
NAT divert to egress interface outside
Untranslate 172.20.0.41/23 to 172.20.0.41/23

Phase: 2
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,outside) source static net-local net-local destination static net-remote net-remote
Additional Information:
Static translate 10.0.0.41/1024 to 10.0.0.41/1024

Phase: 3
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (inside,outside) source static net-local net-local destination static net-remote net-remote
Additional Information:

Phase: 7
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 9
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 10
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 21, packet dispatched to next module

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

Cool! It may have been a combination of fixing the typos and then re-applying the maps and finally introducing interesting traffic.

As far as the remaining issue, can you try the packet-tracer again with the source and destinations addresses equal to the hosts you are testing with. That's a good tool that can be used to good effect to either a. show you why the ASA won't pass certain traffic or b. eliminate the ASA as the cause of the problem. You can run it at both ends with the source and destination roles reversed.

Yes, I'm going to do that right now!

 

I can ping from the EQ side to the HQ side, AND I can open a shared folder on the HQ side. 

 

The reverse still does not work. So frustrating.

When I try to ping from 10.0.0.200 to 172.20.0.16, it fails...but with the test  below, it seems that it should pass?

 

-

 

DTI-HQ# packet-tracer input inside tcp 10.0.0.200 1024 172.20.0.16 23

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,outside) source static net-local net-local destination static net-remote net-remote
Additional Information:
NAT divert to egress interface outside
Untranslate 172.20.0.16/23 to 172.20.0.16/23

Phase: 2
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,outside) source static net-local net-local destination static net-remote net-remote
Additional Information:
Static translate 10.0.0.200/1024 to 10.0.0.200/1024

Phase: 3
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (inside,outside) source static net-local net-local destination static net-remote net-remote
Additional Information:

Phase: 7
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 9
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 10
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 335, packet dispatched to next module

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

That syntax is for a tcp connection on port 23 (ssh). Try this line instead:

     packet-tracer input inside icmp 10.0.0.200 0 0 172.20.0.40

So, I'm actually able to ping machine to machine, both ways.

 

The only problem left is, I can open a fileshare one direction, but not in the other.

 

Any suggestions?

Nothing in the VPN setup should cause that remaining anomalous behavior. I would examine any host-based firewalls (or other intervening access-lists etc. in the network).

ok thank you SO MUCH for your help. I was really in the woods on this one.