09-19-2014 02:11 AM
Dear all,
I have to connect two remote sites using an IPSec Tunnel (EasyVPN). The devices to be used are two Cisco ASA 5505.
They have already been connected to the internet and configured and they can see and ping each other via the “outside” interface. The inside interfaces on both sides have a private address range 192.168.160.0/24 and 192.168.128.0/24.
Before connecting the to the internet I configured them connected to a 2921 Router that simulated the Internet (both interfaces had the adresses of the real gateways). In my test configuration the tunnel was established (checked via show isakmp sa) and two computers connected in the inside interfaces of each ASA could ping each other.
Test Config: *PC*-------*in*ASA*out*-------*2921*----------*out*ASA*in*---------*PC*
The problems came when I connected the ASA devices to the internet. The tunnel is established but I cannot ping devices in the inside interface of the other ASA. Even though the routing table has the correct values.
Real Config: *PC*-------*in*ASA*out*-------*Internet*----------*out*ASA*in*---------*PC*
I am not an expert with the ASA, but as far as I know there shouldn't be a problem with the inside interfaces having a private address, since the whole information is sent through the tunnel, right?
Thanks a lot for your help!
Fabio
09-19-2014 02:29 AM
Hi
Maybe a stupid question, but are you sure you are inspecting icmp?
Otherwise write "fixup protocol icmp".
09-19-2014 04:15 AM
Hello,
thanks for your answer. On both devices I configured icmp as follows:
icmp permit any inside
icmp permit any outside
And the policy map is as follows:
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect esmtp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect ip-options
!
This icmp inspection has something to do? What is puzzling me is the fact that my test configuration with the 2911 router simulating internet works and once I connect it to the real internet it doesn't.
thanks again!
Fabio
09-19-2014 04:55 AM
Hi Fabio,
Can you provide the output of below :
Show run nat
sh route
show cry isa sa
show cry ips sa
Regards,
Altaf
09-19-2014 05:39 AM
Hi,
at the moment I only have access to one of the ASAs (the one acting as server). For security reasons I have changed the public IPs.
Find also attached a schema of the network (at the moment there are no devices connected in the 192.168.160.0 network). When I tested it, there were.
show run nat
ASA# sh run nat
nat (inside) 0 access-list no-nat
nat (inside) 1 0.0.0.0 0.0.0.0
ASA#
sh route
ASA# sh route
Gateway of last resort is 192.168.128.1 to network 0.0.0.0
S 1.1.1.0 255.255.255.224 [1/0] via 2.2.2.1, outside
C 192.168.128.0 255.255.255.0 is directly connected, inside
S 192.168.160.0 255.255.255.0 [1/0] via 2.2.2.1, outside
C 2.2.2.0 255.255.255.224 is directly connected, outside
S* 0.0.0.0 0.0.0.0 [1/0] via 192.168.128.1, inside
show cry isa sa
ASA# sh cry isa sa
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: 1.1.1.2
Type : user Role : responder
Rekey : no State : AM_ACTIVE
show cry ips sa
BB-ERL# sh cry ips sa
interface: outside
Crypto map tag: dyn-bb-map, seq num: 5, local addr: 146.254.60.228
local ident (addr/mask/prot/port): (2.2.2.2/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (1.1.1.2/255.255.255.255/0/0)
current_peer: 1.1.1.2, username: user
dynamic allocated peer ip: 0.0.0.0
#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 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
#send errors: 0, #recv errors: 0
local crypto endpt.: 2.2.2.2, remote crypto endpt.: 1.1.1.2
path mtu 1500, ipsec overhead 74, media mtu 1500
current outbound spi: 5AAC68DB
current inbound spi : EF3D1228
inbound esp sas:
spi: 0xEF3D1228 (4013756968)
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={RA, Tunnel, }
slot: 0, conn_id: 32768, crypto-map: dyn-bb-map
sa timing: remaining key lifetime (sec): 27308
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
outbound esp sas:
spi: 0x5AAC68DB (1521248475)
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={RA, Tunnel, }
slot: 0, conn_id: 32768, crypto-map: dyn-bb-map
sa timing: remaining key lifetime (sec): 27308
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
Crypto map tag: dyn-bb-map, seq num: 5, local addr: 2.2.2.2
local ident (addr/mask/prot/port): (192.168.128.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (1.1.1.2/255.255.255.255/0/0)
current_peer: 1.1.1.2, username: user
dynamic allocated peer ip: 0.0.0.0
#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 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
#send errors: 0, #recv errors: 0
local crypto endpt.: 2.2.2.2, remote crypto endpt.: 1.1.1.2
path mtu 1500, ipsec overhead 74, media mtu 1500
current outbound spi: B66B6785
current inbound spi : 8ADC7777
inbound esp sas:
spi: 0x8ADC7777 (2329704311)
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={RA, Tunnel, }
slot: 0, conn_id: 32768, crypto-map: dyn-bb-map
sa timing: remaining key lifetime (sec): 27309
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
outbound esp sas:
spi: 0xB66B6785 (3060492165)
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={RA, Tunnel, }
slot: 0, conn_id: 32768, crypto-map: dyn-bb-map
sa timing: remaining key lifetime (sec): 27307
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
Thanks a lot!!
Fabio
09-19-2014 07:20 AM
Hi,
Can you check the NAT 0, are you sure you are exempting the traffic, for troubleshooting, please get the packet tracer output. we need to initiate a packet tracer from the inside interface:
something like this:
packet input inside icmp 192.168.128.5 8 0 1.1.1.2 det
you will see where the packet is dropping , if it doesn't then flow should be allowed and goes through VPN.
if you have difficulties, please paste the above output here for analyse.
-Altaf
09-19-2014 07:25 AM
Hi,
thanks for your answer. I don't have access to the devices anymore. I won't be able to do this until monday.
However, in my test scenario, which is the same as the real one but simulating the internet connection using a Cisco2921, I could ping and communicate from both ASA's "inside sides" (I was able to establish a remote desktop session as well!!)
best regards,
Fabio
09-19-2014 07:47 AM
Hi,
One more thing is, if you trying to ping inside interface through the VPN(in non-working one), then please add:
Management-access inside
if not then the packet tracer output will clearly tell you where could be the issue is.
-Altaf
09-21-2014 11:34 PM
Hi,
according to the outputs i copied here, the traffic between both inside networks should be routed through the VPN, right?
In my test scenario it worked flawlessly. It is with the "internet" connection where I have all the problems.
Best regards,
Fabio
09-22-2014 01:13 AM
Hi,
Once you send a ping to the destination from the source 192.168.128.X, observe the output of "sho cry ips sa" and see the counters of encaps/decaps. if the encap counter is not incrementing then then traffic isn't going through the tunnel.
In this case packet tracer command which I highlighted will help.
-Altaf
09-23-2014 06:36 AM
Dear Altaf,
thanks for your message. I did as you requested (from the device 1.1.1.2). When I ping from 192.168.160.x to 192.168.128.x the ENCAPS are incremented, but not the DECAPS (Ping failed). When I ping from 1.1.1.2 to 2.2.2.2 both ENCAPS and DECAPS are incremented (Ping successfull).
I did the packet tracer tests you told me and here is what I got. It looks like the return path is not allowed through the ACL. Am I right?
ASA# packet-tracer input inside icmp 192.168.160.12 8 0 192.168.128.1
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 outside
Phase: 2
Type: ACCESS-LIST
Subtype: aaa-user
Result: ALLOW
Config:
Additional Information:
Phase: 3
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 4
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:
Phase: 5
Type: NAT-EXEMPT
Subtype:
Result: ALLOW
Config:
match ip inside any outside 192.168.128.0 255.255.255.0
NAT exempt
translate_hits = 12, untranslate_hits = 0
Additional Information:
Phase: 6
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside) 1 0.0.0.0 0.0.0.0
match ip inside any outside any
dynamic translation to pool 1 (1.1.1.2 [Interface PAT])
translate_hits = 49, untranslate_hits = 80
Additional Information:
Phase: 7
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
nat (inside) 1 0.0.0.0 0.0.0.0
match ip inside any inside any
dynamic translation to pool 1 (No matching global)
translate_hits = 0, untranslate_hits = 0
Additional Information:
Phase: 8
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:
Phase: 9
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 636, 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
ASA#
ASA# packet-tracer input outside icmp 192.168.128.1 8 0 192.168.160.12
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 192.168.160.0 255.255.255.0 inside
Phase: 2
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
09-23-2014 06:54 AM
Hi,
As per the output, we see ACL, NAT and VPN is correct. It is correctly flowing through the VPN.
Could you confirm if you are using any ACL on the dynamic map on the ezvpn server ?
-Altaf
09-23-2014 07:16 AM
Hi Altaf,
this is the ACL config in the server:
ASA-SRV# sh run
: Saved
:
ASA Version 8.2(5)
!
hostname ASA-SRV
enable password ************* encrypted
passwd *********** encrypted
names
!
interface Ethernet0/0
switchport access vlan 2
!
interface Ethernet0/1
!
interface Ethernet0/2
!
interface Ethernet0/3
!
interface Ethernet0/4
!
interface Ethernet0/5
!
interface Ethernet0/6
!
interface Ethernet0/7
!
interface Vlan1
nameif inside
security-level 100
ip address 192.168.128.2 255.255.255.0
!
interface Vlan2
nameif outside
security-level 0
ip address 2.2.2.2 255.255.255.224
!
ftp mode passive
access-list no-nat extended permit ip 192.168.128.0 255.255.255.0 192.168.160.0 255.255.255.0
access-list bb-traffic extended permit ip 192.168.128.0 255.255.255.0 192.168.160.0 255.255.255.0
pager lines 24
logging asdm informational
mtu inside 1500
mtu outside 1500
no failover
icmp unreachable rate-limit 1 burst-size 1
icmp permit any inside
icmp permit any outside
no asdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 0 access-list no-nat
nat (inside) 1 0.0.0.0 0.0.0.0
route inside 0.0.0.0 0.0.0.0 192.168.128.1 1
route outside 192.168.160.0 255.255.255.0 2.2.2.1 1
route outside 1.1.1.0 255.255.255.224 2.2.2.1 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
timeout floating-conn 0:00:00
dynamic-access-policy-record DfltAccessPolicy
http server enable
http 192.168.128.0 255.255.224.0 inside
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
crypto ipsec transform-set bb-set esp-aes-256 esp-sha-hmac
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
crypto dynamic-map dyn-bb-map 5 set transform-set bb-set
crypto map bb-map 60 ipsec-isakmp dynamic dyn-bb-map
crypto map bb-map interface outside
crypto isakmp enable outside
crypto isakmp policy 1
authentication pre-share
encryption aes-256
hash sha
group 2
lifetime 86400
telnet timeout 5
ssh timeout 5
console timeout 0
dhcpd auto_config outside
!
dhcpd address 192.168.128.100-192.168.128.110 inside
!
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
webvpn
group-policy bbgroup internal
group-policy bbgroup attributes
split-tunnel-policy tunnelspecified
split-tunnel-network-list value bb-traffic
nem enable
username user password ********* encrypted
tunnel-group bb-tunnel type remote-access
tunnel-group bb-tunnel general-attributes
default-group-policy bbgroup
tunnel-group bb-tunnel ipsec-attributes
pre-shared-key **********
!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum client auto
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect esmtp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect ip-options
inspect icmp
!
service-policy global_policy global
prompt hostname context
09-23-2014 07:28 AM
Hi,
Could you remove the split tunnel from the configuration from the group-policy, bounce the tunnel and reconnect and check?
Hopefully this works.
Altaf
09-23-2014 10:52 PM
Hi Altaf,
it is enough if I issue the following commands?
no split-tunnel-policy tunnelspecified
no split-tunnel-network-list value bb-traffic
Or anything else has to be done to remove the split tunnel?
Best regards,
Fabio
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