cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1264
Views
0
Helpful
1
Replies

ASAv on Azure - can't contact tools.cisco.com

BryceAshey05138
Level 1
Level 1

Folks, 

I'm working through the guide found here: https://www.cisco.com/c/en/us/td/docs/security/asa/asa914/configuration/general/asa-914-general-config/ha-failover-cloud.html#id_53631

 

When trying to contact tools.cisco.com (to license the ASAv) it appears the packets are being dropped by the Global deny. Any idea why it would bypass my any/any rule on tcp/https?

 

Gateway of last resort is 10.225.169.97 to network 0.0.0.0

S* 0.0.0.0 0.0.0.0 [1/0] via 10.225.169.97, outside
C 10.225.169.0 255.255.255.248 is directly connected, heartbeat
L 10.225.169.4 255.255.255.255 is directly connected, heartbeat
C 10.225.169.8 255.255.255.248 is directly connected, management
L 10.225.169.12 255.255.255.255 is directly connected, management
C 10.225.169.64 255.255.255.224 is directly connected, inside
L 10.225.169.70 255.255.255.255 is directly connected, inside
C 10.225.169.96 255.255.255.224 is directly connected, outside
L 10.225.169.100 255.255.255.255 is directly connected, outside
S 168.63.129.16 255.255.255.255 [1/0] via 10.225.169.9, management

 

interface GigabitEthernet0/0
nameif inside
security-level 100
ip address 10.225.169.70 255.255.255.224
!
interface GigabitEthernet0/1
nameif outside
security-level 0
ip address 10.225.169.100 255.255.255.224
!
interface GigabitEthernet0/2
nameif heartbeat
security-level 100
ip address 10.225.169.4 255.255.255.248
!
interface Management0/0
no management-only
nameif management
security-level 100
ip address dhcp

 

providervpn-asa01-local# packet-tracer input management 10.225.169.12 443 172.$

packet-tracer input management 10.225.169.12 443 172.37.145.8 443
^
ERROR: % Invalid input detected at '^' marker.
providervpn-asa01-local# packet-tracer input management tcp 10.225.169.12 443 $

Phase: 1
Type: CP-PUNT
Subtype: l2-selective
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7f699410dee0, priority=13, domain=punt, deny=false
hits=27871, user_data=0x7f69940fc5c0, cs_id=0x0, l3_type=0x8
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0000.0000.0000
input_ifc=management, output_ifc=any

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7f6989797000, priority=1, domain=permit, deny=false
hits=188246, user_data=0x0, cs_id=0x0, l3_type=0x8
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0100.0000.0000
input_ifc=management, output_ifc=any

Phase: 3
Type: INPUT-ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
Found next-hop 10.225.169.97 using egress ifc outside

Phase: 4
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7f6994111600, priority=501, domain=permit, deny=true
hits=9, user_data=0x7, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=10.225.169.12, mask=255.255.255.255, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=management, output_ifc=any

Result:
input-interface: management
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame 0x000055c93203eb00 flow (NA)/NA

 

 

Cheers,

Bryce

 

1 Accepted Solution

Accepted Solutions

BryceAshey05138
Level 1
Level 1

Ok - figured this out.

 

There were two problems – one was definitely the default route – the second solution you mention below did the trick there with the addition of moving the default route to the outside interface.

 

Default route fix:

interface management 0/0

ip address dhcp

route management 168.63.129.16 255.255.255.255 <internet gateway of mgmt subnet>

route outside 0.0.0.0 0.0.0.0 <internet gateway of outside subnet>

 

The 168.63.129.16 IP above is Azure's default location for the Azure Wire Server (DNS, etc.)

 

The second fix was a needle in a haystack… Because, in this scenario, the ASAs (with private IPs only) are behind an Azure Load Balancer there MUST be an outbound rule specified (on the Azure Load Balancer) for the Load Balancer’s SNAT to handle the traffic. Reference here: https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-outbound-rules-overview. Without the outbound rule the ASA cannot talk to the public internet (even with the default route in place).

View solution in original post

1 Reply 1

BryceAshey05138
Level 1
Level 1

Ok - figured this out.

 

There were two problems – one was definitely the default route – the second solution you mention below did the trick there with the addition of moving the default route to the outside interface.

 

Default route fix:

interface management 0/0

ip address dhcp

route management 168.63.129.16 255.255.255.255 <internet gateway of mgmt subnet>

route outside 0.0.0.0 0.0.0.0 <internet gateway of outside subnet>

 

The 168.63.129.16 IP above is Azure's default location for the Azure Wire Server (DNS, etc.)

 

The second fix was a needle in a haystack… Because, in this scenario, the ASAs (with private IPs only) are behind an Azure Load Balancer there MUST be an outbound rule specified (on the Azure Load Balancer) for the Load Balancer’s SNAT to handle the traffic. Reference here: https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-outbound-rules-overview. Without the outbound rule the ASA cannot talk to the public internet (even with the default route in place).

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: