NAT/ACL issue when creating a DMZ

kylebrogers · ‎06-15-2017

This is a new DMZ on an ASA running 8.2 code.

Vendor X wants to put several servers in the DMZ in the 172.16.0.0/24 subnet. They want that DMZ subnet to have access to the inside subnets of 10.10.10.0/24 and 10.10.20.0/24 on the services specified by the VendorX-Services-TCP/UDP object groups. They also want to be able to get from their location (2.2.2.2) to the DMZ subnet by connecting to 1.1.1.1 but only using the services allowed in the object-group service VendorX-External-Access-TCP/UDP object-groups.
The DMZ servers should be allowed to get to anywhere on the outside.

I know at this point that they cannot access the DMZ from their IP (2.2.2.2) and I think it's a NAT issue of some kind but was hoping someone could look at the config I'm putting in and let me know what I'm doing wrong. Additionally, could you double check that I have the DMZ > INSIDE stuff set up correctly?

name 172.16.0.10 VendorX-Private-IP
name 1.1.1.1 VendorX-Public-IP

nat (DMZ) 1 0.0.0.0 0.0.0.0

static (DMZ,outside) VendorX-Public-IP VendorX-Private-IP netmask 255.255.255.255
static (inside,DMZ) 10.0.0.0 10.0.0.0 netmask 255.0.0.0
static (inside,DMZ) 172.16.0.0 172.16.0.0 netmask 255.255.255.0

object-group network VendorX-Company-IP
network-object host 2.2.2.2

object-group network VendorX-Internal
network-object 10.10.10.0 255.255.255.0
network-object 10.10.20.0 255.255.255.0

object-group service VendorX-Services-TCP tcp
port-object eq 5985
port-object eq 5986
port-object eq 8443
port-object eq 22
port-object eq 902
port-object eq 903
port-object eq 10080
port-object eq 10443
port-object eq 3389
port-object eq 8080
port-object eq 8443
port-object eq 8444
port-object eq 8445
port-object eq 6970
port-object eq 80
port-object eq 443

object-group service VendorX-Services-UDP udp
port-object eq 161

object-group service VendorX-External-Access-TCP tcp
port-object eq 10000
port-object eq 22

object-group service VendorX-External-Access-UDP udp
port-object eq 500
port-object eq 10000
port-object eq 4500

access-list acl_out line 19 extended permit tcp object-group VendorX-Company-IP host VendorX-Public-IP object-group VendorX-External-Access-TCP
access-list acl_out line 20 extended permit udp object-group VendorX-Company-IP host VendorX-Public-IP object-group VendorX-External-Access-UDP

access-list DMZ_outbound extended permit tcp host VendorX-Private-IP object-group VendorX-Internal object-group VendorX-Services-TCP
access-list DMZ_outbound extended permit udp host VendorX-Private-IP object-group VendorX-Internal object-group VendorX-Services-UDP

access-group acl_out in interface outside
access-group DMZ_outbound in interface DMZ

kylebrogers · ‎06-16-2017

bump

dperezoquendo · ‎06-19-2017

"The DMZ servers should be allowed to get to anywhere on the outside"

I don't see an ACL for that.

I would also suggest running the packet-tracer command to better troubleshoot and isolate the issues.

kylebrogers · ‎06-19-2017

Wow. Not sure how I missed that. I've added an object group and modified the ACL (see below) but I'm still having the issue.

I've run a new packet tracer and pasted the output below that.

_________________

Config Added:

object-group network RFC1918
network-object 10.0.0.0 255.0.0.0
network-object 192.168.0.0 255.255.0.0
network-object 172.16.0.0 255.240.0.0

access-list DMZ_outbound line 3 extended deny tcp host VendorX-Private-IP object-group RFC1918
access-list DMZ_outbound line 4 extended deny udp host VendorX-Private-IP object-group RFC1918
access-list DMZ_outbound line 5 extended permit tcp host VendorX-Private-IP any
access-list DMZ_outbound line 6 extended permit udp host VendorX-Private-IP any

------------------------------

# packet-tracer input outside tcp VendorX-Company-IP 35000 24.249.99.50 22 detailed

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 (DMZ,outside) DMZ-Server-Pub-IP DMZ-Server-Priv-IP netmask 255.255.255.255
match ip DMZ host DMZ-Server-Priv-IP outside any
static translation to DMZ-Server-Pub-IP
translate_hits = 0, untranslate_hits = 13799
Additional Information:
NAT divert to egress interface DMZ
Untranslate DMZ-Server-Pub-IP/0 to DMZ-Server-Priv-IP/0 using netmask 255.255.255.255

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group acl_out in interface outside
access-list acl_out extended permit tcp object-group VendorX-Company-IP host DMZ-Server-Pub-IP eq ssh
object-group network VendorX-Company-IP
network-object host VendorX-Company-IP
Additional Information:
Forward Flow based lookup yields rule:
in id=0xac1405e0, priority=12, domain=permit, deny=false
        hits=10, user_data=0xa89f5340, cs_id=0x0, flags=0x0, protocol=6
        src ip=VendorX-Company-IP, mask=255.255.255.255, port=0
        dst ip=DMZ-Server-Pub-IP, mask=255.255.255.255, port=22, dscp=0x0

Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xab7b3998, priority=0, domain=permit-ip-option, deny=true
        hits=39385078, 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: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xac230e40, priority=12, domain=ipsec-tunnel-flow, deny=true
        hits=2680707, user_data=0x0, cs_id=0x0, 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: 6
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
out id=0xb2a05360, priority=11, domain=permit, deny=true
        hits=25, user_data=0x5, cs_id=0x0, 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

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: DMZ
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

dperezoquendo · ‎06-19-2017

Hmm,

It might be the 2 rules you added:

access-list DMZ_outbound line 3 extended deny tcp host VendorX-Private-IP object-group RFC1918
access-list DMZ_outbound line 4 extended deny udp host VendorX-Private-IP object-group RFC1918

You are untranslating public to private ip but then your denying via other RFC1918s. I don't think you'll be even to talk DMZ to Internal with those 2 ACLs in there.

Try doing a packet-tracer from DMZ to inside as well.

I am also unfamiliar with pre-8.3 NAT statements so bare with me please :).

kylebrogers · ‎06-19-2017

The first two lines in the ACL (before the new ones I put in) granted TCP and UDP access to the inside IPs/ports that I wanted for DMZ > Inside access. I figure that would take care of things before I then denied access to any other RFC1918 IPs. Since the traffic I'm having issues with is traffic from Outside > DMZ, I thought the return traffic would go from the Private DMZ IP > Vendor Company's Public IP so it should hit lines 5 and 6. Are you saying that I might need to have it allow the DMZ public IPs to get out rather than the DMZ private IPs?

No worries on the 8.2 thing. I'm the same way. I appreciate the help.

dperezoquendo · ‎06-19-2017

No. I'm saying all you really need is an ACL allowing your DMZ to talk to Inside and Outside networks as per your customer's requirement. Lines 5 and 6 should be fine.

So really you can delete the line 3 and line 4 of the DMZ_outbound. Unless I'm reading it incorrectly, but these 2 lines appear to deny your vendor private IP from entering the ASA via the DMZ. Your DMZ and Internal subnet falls under the RFC1918 object-group. That server has to be able to reach the ASA for NAT to hit.

For example, try doing a packet-trace from DMZ to outside, and lets see results.

dperezoquendo · ‎06-20-2017

After re-reading, you may be right. Though I still think they should be removed because it looks to me it would block connectivity to inside network. If you want these to remain, then I recommend swapping the order and slightly modifying as such:

access-list DMZ_outbound line 3 extended permit tcp host VendorX-Private-IP any
access-list DMZ_outbound line 4 extended permit udp host VendorX-Private-IP any

access-list DMZ_outbound line 5 extended deny tcp any object-group RFC1918
access-list DMZ_outbound line 6 extended deny udp any object-group RFC1918

I also recommend doing another packet-tracer from DMZ to Outside to see where that fails.

Is this a new DMZ? If so, we may need to look at the routing to ensure the server is reachable... if you haven't done that already.