07-26-2018 09:28 AM - edited 02-21-2020 08:01 AM
Can someone please help me figure out why I can't ping from my Azure VM to any on-premises devices? I've added exclusions for ICMP in Windows Firewalls on both sides and can successfully ping from on-prem (i.e. 192.168.1.90) to an Azure VM (i.e. 10.0.0.1), but not the other way around. I've also added exclusions in Azure NSGs. All other traffic flows successfully. We are currently utilizing a Cisco ASA 5506-X with Firepower. We could ping in both directions when we were using the older ASA 5505, however the config for the two are a bit different (no VLANs on the 5506, using BVI).
Here is my config (anything marked [removed] I deemed sensitive):
Solved! Go to Solution.
07-26-2018 01:55 PM
At the end of each NAT, please add the following keywords: no-proxy-arp route-lookup
07-26-2018 01:56 PM
07-26-2018 07:43 PM
07-26-2018 12:45 PM
Have you tried running a packet-tracer test for icmp traffic from both ingress and egress on the firewall?
Here is the syntax:
packet-tracer input <inside-interface-name> icmp <source-ip> 0 0 <destination-ip>
It should give you a detailed explanation of what happens to the traffic entering and exiting the firewall. If all phases pass then we know the firewall isn't to blame on this issue.
07-26-2018 01:15 PM
Result of the command: "packet-tracer input inside_6 icmp 10.0.0.4 0 0 192.168.1.90"
Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list
Phase: 2
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 192.168.1.90 using egress ifc inside
Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inside_6_access_in in interface inside_6
access-list inside_6_access_in extended permit ip any any
Additional Information:
Phase: 4
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 6
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
class-map inspection_default
match default-inspection-traffic
policy-map global_policy
class inspection_default
inspect icmp
service-policy global_policy global
Additional Information:
Phase: 7
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:
Phase: 8
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
Phase: 9
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 883583, packet dispatched to next module
Result:
input-interface: inside_6
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: allow
07-26-2018 01:32 PM
When you look at the results you can see the output interface is your inside BVI interface, when it should be the outside interface.
In phase 2 route lookup it is saying the next hop is your 192.168.1.90 address which resides on the inside interface. Your 0.0.0.0 route should use the gate way address that is on your outside Comcast interface for traffic to be routed to the outside of the ASA.
07-26-2018 01:47 PM
I'm definitely not an expert on this equipment. What change would you suggest I make and could you help me out with the command?
07-26-2018 01:32 PM
This capture might be more pertinent since we're dealing with a VPN:
Result of the command: "packet-tracer input outside icmp 10.0.0.4 8 0 192.168.1.90"
Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside_1,outside) source static onprem-networks onprem-networks destination static azure-networks azure-networks
Additional Information:
NAT divert to egress interface inside_1
Untranslate 192.168.1.90/0 to 192.168.1.90/0
Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside_access_in in interface outside
access-list outside_access_in extended permit icmp any4 any4
Additional Information:
Phase: 3
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside_1,outside) source static onprem-networks onprem-networks destination static azure-networks azure-networks
Additional Information:
Static translate 10.0.0.4/0 to 10.0.0.4/0
Phase: 4
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 6
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside_access_in in interface outside
access-list outside_access_in extended permit icmp any4 any4
Additional Information:
Phase: 7
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Phase: 8
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 9
Type: VPN
Subtype: ipsec-tunnel-flow
Result: DROP
Config:
Additional Information:
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside_1
output-status: down
output-line-status: down
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
07-26-2018 01:39 PM
I just realized that your inside packet tracer had the IP addresses reversed.. so your source was 10.x and dest was 192.x which would be why the routing looked incorrect.
07-26-2018 01:48 PM - edited 07-26-2018 01:49 PM
I'm having trouble pinging 192.168.1.90 from 10.0.0.4. Not the other way around. I can ping 10.0.0.4 from 192.168.1.90 all day long. The 10.0.0.4 is an Azure VM. The 192.168.1.90 is my on-prem machine.
07-26-2018 01:54 PM
Result of the command: "packet-tracer input inside_6 icmp 192.168.1.90 0 0 10.0.0.4"
Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list
Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside_6,outside) source static onprem-networks onprem-networks destination static azure-networks azure-networks
Additional Information:
NAT divert to egress interface outside
Untranslate 10.0.0.4/0 to 10.0.0.4/0
Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inside_6_access_in in interface inside_6
access-list inside_6_access_in extended permit ip any any
Additional Information:
Phase: 4
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside_6,outside) source static onprem-networks onprem-networks destination static azure-networks azure-networks
Additional Information:
Static translate 192.168.1.90/0 to 192.168.1.90/0
Phase: 5
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 7
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inside_access_in in interface inside
access-list inside_access_in extended permit ip any any
Additional Information:
Phase: 8
Type: NAT
Subtype:
Result: ALLOW
Config:
object network obj_any
nat (any,outside) dynamic interface
Additional Information:
Static translate 192.168.1.90/0 to 192.168.1.90/0
Phase: 9
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Phase: 10
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 11
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
class-map inspection_default
match default-inspection-traffic
policy-map global_policy
class inspection_default
inspect icmp
service-policy global_policy global
Additional Information:
Phase: 12
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:
Phase: 13
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
Phase: 14
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:
Phase: 15
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
class-map inspection_default
match default-inspection-traffic
policy-map global_policy
class inspection_default
inspect icmp
service-policy global_policy global
Additional Information:
Phase: 16
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:
Phase: 17
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
Phase: 18
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:
Phase: 19
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (inside_6,outside) source static onprem-networks onprem-networks destination static azure-networks azure-networks
Additional Information:
Phase: 20
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 911015, packet dispatched to next module
Result:
input-interface: inside_6
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow
This shows the ping is working from 192.168.1.90 to 10.0.0.4, correct?
07-26-2018 01:03 PM
Hi, I see your traffic should go through a VPN tunnel towards the Azure VMs. A packet tracer will let you know if traffic is going encrypted through the tunnel on a phase, but may not let us know if it is dropped by a rule, or something similar.
I would suggest to additionally take some asp captures (capture asp type asp-drop all match host [src-OnPrm-host] host [dst-Azure-host]
This will give us more information on the drop reason for that specific traffic.
Additionally, have there been any other changes apart from the asa5505 to asa5506 that we should be aware of?
07-26-2018 01:16 PM
No other major changes between the 5505 and 5506 that I'm aware of. It might be pertinent to know that this Site-to-Site VPN is using policy-based traffic selectors (it is route-based VPN but must utilize the policy-based traffic selectors to make it work).
07-26-2018 01:55 PM
At the end of each NAT, please add the following keywords: no-proxy-arp route-lookup
07-26-2018 01:56 PM
07-26-2018 02:07 PM
07-26-2018 07:43 PM
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