05-10-2011 02:43 PM - edited 03-11-2019 01:31 PM
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!
05-10-2011 05:49 PM
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
05-12-2011 08:27 AM
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.
05-12-2011 08:41 AM
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
This should definitely work.
Let me know how it goes.
Thanks,
Varun
05-12-2011 08:53 AM
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
05-12-2011 09:16 AM
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!
05-12-2011 10:26 AM
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
thanks,
Varun
05-12-2011 10:54 AM
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
05-12-2011 11:02 AM
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
05-12-2011 12:19 PM
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
05-12-2011 11:03 PM
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
access-list cap permit ip 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
05-13-2011 09:52 AM
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
05-13-2011 01:50 PM
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!
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