05-11-2014 10:53 PM
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
Solved! Go to Solution.
05-12-2014 11:22 AM
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#
05-12-2014 11:39 AM
Can you run that packet-tracer once again with the "detailed" keyword? (You might want to "undebug all" first.)
05-12-2014 12:01 PM
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
05-12-2014 12:12 PM
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.
05-12-2014 12:14 PM
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.
05-12-2014 12:29 PM
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
05-12-2014 12:29 PM
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
05-12-2014 01:56 PM
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?
05-12-2014 03:00 PM
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).
05-12-2014 03:09 PM
ok thank you SO MUCH for your help. I was really in the woods on this one.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide