Cisco ASA CX

[Ashley Sahonta]

Hi,

I have configured the CX to filter URLs, however I am having issues with the updates. It seems that the CX module can't access the internet.

How do I configure the CX/management interface of the ASA to reach the internet so that it can perform updates?

Cheers,

Ash

[Marvin Rhoads]

The CX uses the ASA management interface (on the 5512X through 5555X). You need a default route for the management interface on the ASA.

See the CX Quick Start Guide here for more details.

[Ashley Sahonta]

There is a default route for the management network, however it does not get out to the internet..?

[Marvin Rhoads]

The route doesn't need to point to the Internet per se but traffic sourced from the ASA / CX management interface to that gateway must be able to reach the Internet and get replies back.

A quick test is, from the ASA: "ping management 8.8.8.8".

[Ashley Sahonta]

Yeah, I get that the gateway must reach the internet, but it's not currently.

Do you know if there are any particular steps required to allow the management access to get internet access. When I run the packet tracer I get the following output -

myvpn# packet-tracer input management icmp 10.0.125.2 8 0 4.2.2.2 detailed

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: mgmt-deny-all

Result: DROP

Config:

Additional Information:

Forward Flow based lookup yields rule:

in  id=0x7fff9f352740, priority=200, domain=mgmt-lockdown, deny=true

        hits=2, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0

        src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0

        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0 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

[Marvin Rhoads]

On my working CX, I see I have a default route set on the cx itself:

seclabcx>show route

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

192.168.100.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0

127.0.0.0       0.0.0.0         255.255.0.0     U     0      0        0 cplane

0.0.0.0         192.168.100.254 0.0.0.0         UG    0      0        0 eth0

I believe this is done during the CX setup.

[Ashley Sahonta]

I have the default route on the CX set to our core switch, as stated on the setup guide.

Does your default route point to the ASA management interface?

[Marvin Rhoads]

My default route for the CX is the core switch's L3 interface on the VLAN that the ASA / CX module management interface is assigned to:

seclabcx>show int

eth0      Link encap:Ethernet  HWaddr 50:3D:E5:9E:38:70 

          inet addr:192.168.100.6  Bcast:192.168.100.255  Mask:255.255.255.0

SECLABCORE#sh mac address-table | i 3870

100    503d.e59e.3870   dynamic ip,other              GigabitEthernet2/5   

SECLABCORE#

SECLABCORE#sh run int gi2/5

Building configuration...

Current configuration : 146 bytes

!

interface GigabitEthernet2/5

description ASA-CX module

switchport access vlan 100

logging event link-status

logging event trunk-status

end

SECLABCORE#show ip int br | i 100.254

Vlan100                192.168.100.254 YES NVRAM  up                    up     

SECLABCORE#

[Ashley Sahonta]

Hmmmm. I have no idea why this isn't working then. Are you able to ping from the switch out the internet if you source the ping from VLAN 100?

[Marvin Rhoads]

Yes, I am able to do that:

SECLABCORE#ping 8.8.8.8 source vlan 100

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:

Packet sent with a source address of 192.168.100.254

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 20/20/20 ms

SECLABCORE#

Can you potentially look at your firewall logs or packet capture to see if the traffic is seen when originated from your CX?

[Ashley Sahonta]

Just did a capture on the management interface and it shows as 0 whilst running continuous pings from the CX.

capture CX type raw-data trace interface management [Capturing - 0 bytes]

[Marvin Rhoads]

Actually I was thinking of looking for traffic from the CX while it transits the firewall inside interface.

If your setup is like mine the flow is:

ASA CX interface = physically the ASA's m0/0 but logically separate thus a capture from the ASA won't see it

to

core switch SVI = default gateway of CX

to

ASA Inside interface = default route for Interrnet-bound traffic

It's on that Inside interface that I would capture to troubleshoot and isolate the problem.

Re the NAT, on my lab firewall it's a simple dynamic NAT using the outside interface address:

object network Inside-Any-Hide

subnet 0.0.0.0 0.0.0.0

description Inside-PAT-Hide

object network Inside-Any-Hide

nat (transit-inside,outside) dynamic interface

[Ashley Sahonta]

Yeah, my setup is the same as your's.

Output from capture -

20: 16:53:49.113077       802.1Q vlan#5 P0 10.0.125.2 > 4.2.2.2: icmp: echo request

  21: 16:53:50.113351       802.1Q vlan#5 P0 10.0.125.2 > 4.2.2.2: icmp: echo request

  22: 16:53:50.958278       802.1Q vlan#5 P0 10.0.125.2.51529 > 208.90.58.5.443: S 1355489554:1355489554(0) win 5840

[Marvin Rhoads]

So the capin shows your CX traffic (both the ping and what is probably an attempt to reach Cisco on port 443) going into the firewall - that's good.

Working it hop-by-hop I would next look to see:

Is it going out the other side? Is it NATted as expected? Is there any WCCP redirection or other proxy involved?

If it's going out the other side, are the replies coming in and allowed back through?

[Ashley Sahonta]

NAT is showing -

(inside) to (outside) source dynamic CX-MANAGEMENT interface

    translate_hits = 15, untranslate_hits = 17

Not using any proxies