cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3885
Views
0
Helpful
12
Replies

DMZ to Inside on ASA 5510

chrisb-sitka
Level 1
Level 1

Hello,

I have deployed a read only domain controller in our DMZ as part of a domain-related project.  That machine needs to be able to reach domain controllers on our internal network.  To do so, it should traverse our ASA 5510, going from the DMZ Interface (security level set to 60) to the Inside Interface (security level set to 99).

I've created an ACL as following (alerting hostnames in the example):

access-list dmz_access_in extended permit ip host dmz.rodc.domain.local object-group int-domain-controllers

I've read in various spots that you have to create a NAT when traversing security levels, going from a less trusted interface (DMZ) to a more trusted one (internal.)  Since this link will carry domain traffic, we do not want to create a real translation.  Thus, I created a stand-in NAT that points to its own IP as follows:

static (dmz,inside) dmz.rodc.domain.local dmz.rodc.domain.local netmask 255.255.255.255

Long story short, the connection fails.  I'm able to access other hosts in the DMZ and on another interface configured with the same security level (which I've explicitly allowed), but trying to go from the less-trusted DMZ to the more-trusted internal fails.

I'd appreciate any suggestions as to what I might have missed here.

Thanks!

12 Replies 12

Maykol Rojas
Cisco Employee
Cisco Employee

Hi Chris,

You are right, however, what you need to translate is the host on the inside and not the one on the DMZ. Please add an static translation for the host on the inside like you did for the DMZ.

Cheers.

Mike

Mike

Hi Mike,

Thank you for the reply.

I changed the NAT rule to read:

static (inside,dmz) int.dc.domain.local int.dc.domain.local netmask 255.255.255.255

The connection still does not work, however.

What I suspect is causing the problem is the fact that we have some NAT exempt rules setup that apply to our internal subnet, and they might be misconfigured or may be rendering the NAT listed above useless.  They are:

nat (inside) 0 access-list inside_nat0_outbound

nat (inside) 1 192.168.10.0 255.255.255.0

In our case, inside_nat0_outbound refers to the addresses we use in our VPN pool as well as the DMZ subnet I'm trying to establish connectivity with.

So, is the problem here that we are not applying the static NAT (the "translate our internal domain controller address to itself" rule I noted above), because it is exempt from NAT'ing?  If that's what's happening, is there a way to somehow explicitly NAT just that machine but leave the other exempt rules in place?

Thanks again for the help.

Chris,

Mike was spot on with the NAT configuration. But if you think that NAT exemp might be the culprit, because on an ASA whenever packet hits on the firewall then exempt always takes precedence over static. If you have an ACL defined in the NAT exempt whihc includes the network in which your DMZ server lies then only for that particular server we can put a deny on line 1 in the NAT exempt ACL's.

What this would do is deny the traffic destined for only that DMZ server to be exempted, it would then hit the static statement that you have added. Here is an example:

access-list  inside_nat0_outbound line 1 extended deny ho ho

This should definitely work.

Let me know how it goes.

Thanks,

Varun

Thanks,
Varun Rao

Chris,

here is your order of precedence for nat:

1. NAT exemption (nat 0 access-list)
2. Static NAT and Static PAT (regular and policy) (static)
3.Policy dynamic NAT (nat access-list)
4.Regular dynamic NAT (nat)

Thanks,

Varun

Thanks,
Varun Rao

Hi Varun,

Thanks very much for the tips.

I applied the following access-list change:

access-list inside_nat0_outbound line 1 extended deny ip host int.dc.domain.local host dmz.rodc.domain.local

When I check the running config, that rule appears where it should, as the first entry in the inside_nat0_outbound ACL.

Unfortunately, I'm still not able to get connectivity from the DMZ machine to the internal one.

So, in sum:

1. There is an ACL on the DMZ interface explicitly allowing the DMZ machine to access the internal machine.

2. The NAT exempt ACL should now ignore the internal machine.

3. Then the internal machine should be NAT'd to itself when going from the inside -> DMZ, in the process allowing the connection from a less-trusted security level (DMZ) to a more trusted one (inside.)

Any other thoughts as to why I'm unable to establish connectivity?  I know that the security context issue is the problem, since I can connect from the internal machine to the DMZ directly and I can connect from the DMZ machine to other hosts in the same security level.

Thanks again!

Chris,

Do you have this NAT in the config:

nat (DMZ) 10 0 0

global (inside) 10 interface

and also:

access-list dmz_access_in extended permit ip any host

access-group dmz_access_in in interface DMZ

if this still doesnt work, then i would need a packet-tracer:

packet-tracer input DMZ tcp  2345 443 detailed

thanks,

Varun

Thanks,
Varun Rao

Varun,

The access list allowing the DMZ machine to the internal machine is:

access-list dmz_access_in extended permit ip host dmz.rodc.domain.local host int.dc.domain.local

access-group dmz_access_in in interface dmz

I do not have either of the NAT statements you mentioned, however - there are no NAT statements associated with the dmz interface, and the NAT statements associated with the internal interface are:

nat (inside) 0 access-list inside_nat0_outbound

nat (inside) 1 192.168.10.0 255.255.255.0

The latter refers to:

global (outside) 1 -our external ip- netmask -our external netmask-

(this is our shared external ip for internal machines going out to the internet)

Looking at your suggestions, I'm afraid I don't follow - what does the NAT (interface-name) 10 statement do?  Do I want a NAT applied to the DMZ interface as well as the internal machine I'm trying to connect to (i.e. the "NAT to itself" rule)?  And is a global rule necessary for the internal interface, rather than the host-specific ones I'm working with now?

Thanks again for your helpful suggestions.

-Chris

Chris,

We would need to translate the packets going from DMZ to inside as well, thats why the nat global command, If you have a look at the config it is :

nat (DMZ) 10 0 0

global (inside) 10 interface

This is, all the users going from DMZ to inside would be patted to the inside interface, so the server on inside would see the packets coming from the inside interface ip.

let me know if this work.

Thanks,

Varun

Thanks,
Varun Rao

Varun,

Thank you for the explanation.  In our case, since the goal is to pass Windows domain traffic back and forth, I'd really like to avoid any "real" address translation (by which I mean the inside machine seeing traffic from the outside machine coming from a NAT'd / PAT'd address rather than its "real" address).

Basically, everything is in place that "should" be in place, as far as I can see: the ACL and the NAT, with the new rule to make sure the NAT exemption is not applied to the internal machine.

Here is the output from a packet trace, which claims that the packet should be allowed:

Phase: 1

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found no matching flow, creating a new flow

Phase: 2

Type: UN-NAT

Subtype: static

Result: ALLOW

Config:

static (inside,dmz) int.dc.domain.local int.dc.domain.local netmask 255.255.255.255

  match ip inside host int.dc.domain.local dmz any

    static translation to int.dc.domain.local

    translate_hits = 509, untranslate_hits = 37

Additional Information:

NAT divert to egress interface inside

Untranslate int.dc.domain.local/0 to int.dc.domain.local/0 using netmask 255.255.255.255

Phase: 3

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group dmz_access_in in interface dmz

access-list dmz_access_in extended permit ip host dmz.rodc.domain.local host int.dc.domain.local

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xd7cd9900, priority=12, domain=permit, deny=false

    hits=0, user_data=0xd689c380, cs_id=0x0, flags=0x0, protocol=0

    src ip=dmz.rodc.domain.local, mask=255.255.255.255, port=0

    dst ip=int.dc.domain.local, mask=255.255.255.255, port=0, dscp=0x0

Phase: 4

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xd7cdbe20, priority=0, domain=permit-ip-option, deny=true

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

    src ip=0.0.0.0, mask=0.0.0.0, port=0

    dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 5

Type: NAT-EXEMPT

Subtype: rpf-check

Result: ALLOW

Config:

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xd7b830a8, priority=6, domain=nat-exempt-reverse, deny=true

    hits=1, user_data=0xd8d603a8, cs_id=0x0, use_real_addr, flags=0x0, protocol=0

    src ip=dmz.rodc.domain.local, mask=255.255.255.255, port=0

    dst ip=int.dc.domain.local, mask=255.255.255.255, port=0, dscp=0x0

Phase: 6

Type: NAT

Subtype:

Result: ALLOW

Config:

static (dmz,inside) dmz.rodc.domain.local dmz.rodc.domain.local netmask 255.255.255.255

  match ip dmz host dmz.rodc.domain.local inside any

    static translation to dmz.rodc.domain.local

    translate_hits = 1, untranslate_hits = 5

Additional Information:

Static translate dmz.rodc.domain.local/0 to dmz.rodc.domain.local/0 using netmask 255.255.255.255

Forward Flow based lookup yields rule:

in  id=0xd7c93340, priority=5, domain=nat, deny=false

    hits=0, user_data=0xd834ac88, cs_id=0x0, flags=0x0, protocol=0

    src ip=dmz.rodc.domain.local, mask=255.255.255.255, port=0

    dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 7

Type: NAT

Subtype: host-limits

Result: ALLOW

Config:

static (dmz,inside) dmz.rodc.domain.local dmz.rodc.domain.local netmask 255.255.255.255

  match ip dmz host dmz.rodc.domain.local inside any

    static translation to dmz.rodc.domain.local

    translate_hits = 1, untranslate_hits = 5

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xd7c03938, priority=5, domain=host, deny=false

    hits=1, user_data=0xd834ac88, cs_id=0x0, reverse, flags=0x0, protocol=0

    src ip=dmz.rodc.domain.local, mask=255.255.255.255, port=0

    dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 8

Type: NAT

Subtype: rpf-check

Result: ALLOW

Config:

static (inside,dmz) int.dc.domain.local int.dc.domain.local netmask 255.255.255.255

  match ip inside host int.dc.domain.local dmz any

    static translation to int.dc.domain.local

    translate_hits = 509, untranslate_hits = 37

Additional Information:

Forward Flow based lookup yields rule:

out id=0xd7d33ee8, priority=5, domain=nat-reverse, deny=false

    hits=1, user_data=0xd89a2b00, cs_id=0x0, flags=0x0, protocol=0

    src ip=0.0.0.0, mask=0.0.0.0, port=0

    dst ip=int.dc.domain.local, mask=255.255.255.255, port=0, dscp=0x0

Phase: 9

Type: NAT

Subtype: host-limits

Result: ALLOW

Config:

static (inside,dmz) 192.168.10.0 192.168.10.0 netmask 255.255.255.0

  match ip inside 192.168.10.0 255.255.255.0 dmz any

    static translation to 192.168.10.0

    translate_hits = 84200, untranslate_hits = 77

Additional Information:

Reverse Flow based lookup yields rule:

in  id=0xd8c199a0, priority=5, domain=host, deny=false

    hits=355127, user_data=0xd8b07388, cs_id=0x0, reverse, flags=0x0, protocol=0

    src ip=192.168.10.0, mask=255.255.255.0, port=0

    dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 10

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Reverse Flow based lookup yields rule:

in  id=0xd7c4e770, priority=0, domain=permit-ip-option, deny=true

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

    src ip=0.0.0.0, mask=0.0.0.0, port=0

    dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 11

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 23609193, packet dispatched to next module

Module information for forward flow ...

snp_fp_tracer_drop

snp_fp_inspect_ip_options

snp_fp_tcp_normalizer

snp_fp_translate

snp_fp_adjacency

snp_fp_fragment

snp_ifc_stat

Module information for reverse flow ...

snp_fp_tracer_drop

snp_fp_inspect_ip_options

snp_fp_translate

snp_fp_tcp_normalizer

snp_fp_adjacency

snp_fp_fragment

snp_ifc_stat 

Result:

input-interface: dmz

input-status: up

input-line-status: up

output-interface: inside

output-status: up

output-line-status: up

Action: allow

Very puzzling!

Thanks again for the help.

-Chris

Chris,

Well thats really surprising that the traffic is being allowed by the firewall but still we see ping drops. To troubleshoot it further could you plz provide the following information (only for this specific traffic):

show access-list dmz_access_in

show access-list  inside_nat0_outbound

show run static

show run nat

show run icmp

Along with this I would request you to take the captures on the two interafces as well, follwoing would be the config for it.

access-list cap permit ip ho ho

access-list cap permit ip ho ho

capture capin access-list cap interface inside

capture capdmz access-list cap interface DMZ

And after this you need to generate some traffic, after that do "show capture capin" and "show capture capdmz"

Collect the output and verify where the packets are getting dropped. Simaltaneouly logs from the time of the issue would be really helpful, because in the logs we can why the firewall is dropping the packets.

I would also do a quick recreate of the issue at my end, so let nail this issue down

Thanks,

Varun

Thanks,
Varun Rao

Varun,

I just spent some time with one of our senior admins looking at this problem and running a number of tests (tricky, since it's a production system.)  What we determined, from running packet captures, is that the traffic is being stopped on the reply from the inside back to the dmz.  We were able to follow ICMP packets as follows:

DMZ machine -> DMZ interface -> Inside interface -> Inside machine -> Inside interface -> STOPPED

We do not see the reply packets emerge from the DMZ interface; they are stopped "in between" the inside and dmz interfaces.

For the sake of testing, we put an "allow any any" rule in  place for the DMZ interface (not as dangerous as it sounds in our case,  as we have all external connections going through a seperate  firewall.)  Thus, we know that the ACL on the DMZ interface isn't the  problem.

Now, the issue almost certainly has something to do with our NAT rules, because only our internal network is affected.  They are:

5510# sho run nat
nat (inside) 0 access-list inside_nat0_outbound
nat (inside) 1 192.168.10.0 255.255.255.0

inside_nat0_outbound exempts any connection going to a number of our DMZ servers and our VPN pool from being NAT'd.  An example is:

access-list inside_nat0_outbound line 2 extended permit ip any host dmz.test.domain.local

Now, the trick here is that the "nat (inside) 1 192.168.10.0 255.255.255.0" line may (?) be mangling the replies somehow, even though the exempt rules are supposed to prevent that from happening.

As ever, any insights and suggestions are most welcome!

Thanks again,

-Chris

I resolved the problem this afternoon, but unfortunately I don't have an explanation regarding its cause.  My resolution consisted of routing the connection through a different firewall, so whatever the issue was (is) with the original firewall is still unclear.

That said, this was a very useful experience for me in grappling with security levels, ACLs, and NATs, and I hope the record of the conversation will be useful for other folks who run into similar issues.

Many thanks to Varun for the numerous helpful suggestions!

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: