ASA 5512X - Ping into DMZ not possible after update (9.1(4) to 9.1(7))

[Christian Balzereit]

Hey all,

after I update from 9.1(4) to 9.1(7) I'm not able to access DMZ devices from my internal network.

What are the changes where do I have to look?

Do you need further information?

Thanks in advance.

[Christian Balzereit]

Thx again.

Same errors with the Interim build :(

[Michael Braun]

Same here, even tried latest 9.2.x.x interim, no change, NAT keeps failing. I have a case open with Cisco because of that, once i get some infos, i will be posting.

Cheers everyone, (off to some other problem)

Markus

 Cisco ID CSCO11583512
CCDA, CCNA, CCNA Security, CCNP Security
ASA Specialist, Firewall Security Specialist, IOS Security Specialist,
IPS Specialist, VPN Security Specialist, NSA CNSS 4011 and 4013 Recognition, INFOSEC

Amideo Networks

Ringeisenstrasse 2, 86836 Graben / GT Lagerlechfeld
Phone: +49 8232 956 9197  ,   Fax: +49 8232 959 4031

Amideo Networks Public IPv6 Address Range: 2003:44:2010::/48 ipv6.amideo.de
IPv6 DNS Deutsche Telekom: 2003:40:2000::53, 2003:56::53, 2003:40:4000::53

[Michael Braun]

It may be another issue entirely. The image above does NAT from DMZ to outside, so this is correct. For LAN/DMZ you should use NAT BEFORE Object NAT, unless there is a specific reason not to.... So it may be that with the upgrade, the ASA is a little bit more picky about NAT rules. Do you see any error messages in the log? Usually the ASA is very chatty if there is a problem.

Interface security Level is another this to keep in mind with NAT, and do you realy NAT from LAN to DMZ or is it just identity NAT, so no translation is done?

[Christian Balzereit]

Hello Michael,

Intern -> DMZ = No NAT

DMZ -> outside = Static NAT

NAT for VPN

EDIT: When I access my intern LAN via VPN I'm able to access my DMZ

[Michael Braun]

Have you debugged at the console ?

Debug trace icmp

and you see if and what happens to the packets.

But you may want to stop Nagius/Solarwinds etc. for this or you will get a ton of messages.

Alternatively logg debug to syslog and filter it out.

[Christian Balzereit]

Ok, after I traced icmp the log shows the problem:

ICMP echo request from inside:192.168.111.26 to DMZ:192.168.67.155 ID=1 seq=660 len=32
ICMP echo reply from DMZ:192.168.67.155 to outside:192.168.111.172 ID=45 seq=13583 len=32

The reply goes to the outside interface?? It should be the inside interface.

[Christian Balzereit]

Oh my gosh - I'm an idiot.

I had my VPN Pool in the same ip address area like my internal network (don't ask why).

Because of the NAT Rules for the vpn the asa routed the packets to the outrside interface. Dunno why it worked with 9.1(4).

Now I updated to the suggested 9.4.2 Interim. This version should fix the IKE vuln (because it's from the 28-JAN)?

[Christian Balzereit]

Little question till I'm able to update:

Are the follwoing commands enough to prevent the IKE vuln?

no crypto ikev1 enable outside

no crypto ikev2 enable outside

[Michael Braun]

yes, with ike disabled, no vulnerability, according to Cisco.

But ike must be disabled on ALL interfaces, not just outside, otherwise the control plane is still listening for ike packets. in addition, you can add a control-plane access-list to block all udp/500 and tcp/10000

[Christian Balzereit]

Why should the ASA listen on VPN on inside interfaces?!

[Michael Braun]

No its not global, "outside" in the ike line is the binding to your named "outside" interface.

Because some customers have VPNs through LAN, that is e.g. when you have cry ike ena inside, or DMZ or whatever your interfaces are named via nameif command.

As long as one ike is enabled, regardless of the interface, it will be listening on the control plane and could still be vulnerable.

[David99]

Hi,

I think a few of my posts were a little lost in the comments but have you tried removing and re-adding the NAT statements with the 'no-proxy-arp route-lookup' commands on the end to fix this like I mentioned in another reply?

I've seen this a few times now and fixed it by doing this; even just had a case this morning, though in my case today it was traffic not being sent over the VPN tunnel.