ā02-29-2016 05:08 PM
I was asked to put a second set of eyes on this tunnel for Microsoft Azure and was told that the tunnel could not be established. It sounded as if Microsoft could see the request, but would be followed by an immediate message from the ASA to close the connection. I ran a debug and have attached the output. Any help would be greatly appreciated.
ā03-02-2016 08:42 AM
Try this, get a host behind
capture
[this shows all the packets getting dropped on the ASA ]
run the pings from the host and check the output of
show cap asp | in <x.x.x.x>
x.x.x.x being remote IP in 10.1.1.0 that you are pinging.
This will show if any ICMP packets are getting dropped on
At
Regards,
Dinesh Moudgil
P.S. Please rate helpful posts.
ā03-02-2016 08:52 AM
Nothing seems to be showing up in the capture:
Rinchem-AB3-ASAFW/pri/act(config)# clear crypto ipsec sa counters
Rinchem-AB3-ASAFW/pri/act(config)# sh crypto ipsec sa peer 104.42.185.111
peer address: 104.42.185.111
Crypto map tag: partner-map, seq num: 1, local addr: 63.225.12.2
access-list azure-vpn-acl extended permit ip 192.168.0.0 255.255.0.0 10.1.0.0 255.255.254.0 log
local ident (addr/mask/prot/port): (192.168.0.0/255.255.0.0/0/0)
remote ident (addr/mask/prot/port): (10.1.0.0/255.255.254.0/0/0)
current_peer: 104.42.185.111
#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
#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.: 63.225.12.2/0, remote crypto endpt.: 104.42.185.111/0
path mtu 1500, ipsec overhead 74(44), media mtu 1500
PMTU time remaining (sec): 0, DF policy: clear-df
ICMP error validation: disabled, TFC packets: disabled
current outbound spi: BB9C4A86
current inbound spi : DF965B59
inbound esp sas:
spi: 0xDF965B59 (3751172953)
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv1, }
slot: 0, conn_id: 102350848, crypto-map: partner-map
sa timing: remaining key lifetime (kB/sec): (86999998/1418)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x0000003F 0xFFFFFFFD
outbound esp sas:
spi: 0xBB9C4A86 (3147582086)
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv1, }
slot: 0, conn_id: 102350848, crypto-map: partner-map
sa timing: remaining key lifetime (kB/sec): (86999998/1418)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
Rinchem-AB3-ASAFW/pri/act(config)# capture asp type asp-drop all
Rinchem-AB3-ASAFW/pri/act(config)# sh crypto ipsec sa peer 104.42.185.111
peer address: 104.42.185.111
Crypto map tag: partner-map, seq num: 1, local addr: 63.225.12.2
access-list azure-vpn-acl extended permit ip 192.168.0.0 255.255.0.0 10.1.0.0 255.255.254.0 log
local ident (addr/mask/prot/port): (192.168.0.0/255.255.0.0/0/0)
remote ident (addr/mask/prot/port): (10.1.0.0/255.255.254.0/0/0)
current_peer: 104.42.185.111
#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
#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.: 63.225.12.2/0, remote crypto endpt.: 104.42.185.111/0
path mtu 1500, ipsec overhead 74(44), media mtu 1500
PMTU time remaining (sec): 0, DF policy: clear-df
ICMP error validation: disabled, TFC packets: disabled
current outbound spi: BB9C4A86
current inbound spi : DF965B59
inbound esp sas:
spi: 0xDF965B59 (3751172953)
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv1, }
slot: 0, conn_id: 102350848, crypto-map: partner-map
sa timing: remaining key lifetime (kB/sec): (86999998/1389)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x0000003F 0xFFFFFFFD
outbound esp sas:
spi: 0xBB9C4A86 (3147582086)
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv1, }
slot: 0, conn_id: 102350848, crypto-map: partner-map
sa timing: remaining key lifetime (kB/sec): (86999998/1389)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
Rinchem-AB3-ASAFW/pri/act(config)# sh capt | i 104.42.185.111
Rinchem-AB3-ASAFW/pri/act(config)#
ā03-02-2016 09:01 AM
If you have got host behind ASA, run the pings to remote side from that host and apply the following capture on ASA
capture cap interface inside match ip host 1.1.1.1 host 2.2.2.2
1.1.1.1 - host IP
2.2.2.2 - remote side IP
if the internal routing is correct , then you should see packets in the output of
show capture cap
Please make sure your internal devices have a route for 10.1.0.0 pointing to ASA's inside interface.
Regards,
Dinesh Moudgil
P.S. Please rate helpful posts.
ā03-02-2016 10:17 AM
The capture was empty again. I think at this point there may be a routing issue, although I can not ping across the tunnel from the ASA either. Shouldn't I be able to do that?
ā03-02-2016 10:33 AM
Correct me if I am wrong but your inside interface IP is in the network of 192.168.209.0 and since you allowed only 192.168.0.0 255.255.0.0 to be able to talk to 10.1.0.0
Regards,
Dinesh Moudgil
P.S. Please rate helpful posts.
ā03-03-2016 07:19 AM
Here are my interfaces:
interface GigabitEthernet0/0
nameif outside
security-level 0
ip address X.225.12.2 255.255.255.0 standby X.225.12.4
!
interface GigabitEthernet0/1
nameif inside
security-level 100
ip address 192.168.209.6 255.255.255.0 standby 192.168.209.7
ā03-03-2016 08:39 AM
Regards,
Dinesh Moudgil
P.S. Please rate helpful posts.
ā03-03-2016 08:58 AM
So I had someone ping from the Azure network ping something in our internal network and got no response. The other weird thing is that his IP address was 10.0.0.4, not a 10.1.0.x IP.
ā03-03-2016 09:04 AM
Like discussed in previous posts, the only traffic deemed to traverse VPN tunnel is from 192.168.0.0 255.255.0.0 to 10.1.0.0 255.255.255.0, so no other traffic will go
Regards,
Dinesh Moudgil
P.S. Please rate helpful posts.
ā03-09-2016 08:51 AM
Well, now that they tested the CORRECT environment we have found that the tunnel is working. Thank you so much for your help and patience!
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