Tunnel to Microsoft Azure fails to come up - Page 3

chance gearhart · ‎02-29-2016

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.

Dinesh Moudgil · ‎03-02-2016

Ideally if you are sending 5 ICMP packets and everything is correctly setup, you should see 5 encaps on the tunnel and depending on whether remote side allows ICMP or not , we will see the decaps.

Try this, get a host behind ASA , run this capture

capture asp type asp-drop all
[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 firewall.

At same time , clear the counters using the command I shared before and run "show crypto ipsec sa peer 104.42.185.111 | in encaps|decaps|ident" again and confirm if you see as many encaps as you sent ICMP pings.

Regards,
Dinesh Moudgil

P.S. Please rate helpful posts.

Cisco Network Security Channel - https://www.youtube.com/c/CiscoNetSec/

chance gearhart · ‎03-02-2016

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)#

Dinesh Moudgil · ‎03-02-2016

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.

Cisco Network Security Channel - https://www.youtube.com/c/CiscoNetSec/

chance gearhart · ‎03-02-2016

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?

Dinesh Moudgil · ‎03-02-2016

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 255.255.255.0 , thus you will not be able to initiate traffic from firewall across VPN tunnel.

Regards,
Dinesh Moudgil

P.S. Please rate helpful posts.

Cisco Network Security Channel - https://www.youtube.com/c/CiscoNetSec/

chance gearhart · ‎03-03-2016

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

Dinesh Moudgil · ‎03-03-2016

Thats right, so if you ping from firewall., that would not classify as traffic over VPN tunnel and you wont see the reply from the remote host.

Regards,
Dinesh Moudgil

P.S. Please rate helpful posts.

Cisco Network Security Channel - https://www.youtube.com/c/CiscoNetSec/

chance gearhart · ‎03-03-2016

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.

Dinesh Moudgil · ‎03-03-2016

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 across the tunnel to remote peer.

Regards,
Dinesh Moudgil

P.S. Please rate helpful posts.

Cisco Network Security Channel - https://www.youtube.com/c/CiscoNetSec/

chance gearhart · ‎03-09-2016

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!