ā06-15-2017 06:27 AM - edited ā03-12-2019 02:35 AM
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
ā06-16-2017 06:08 AM
bump
ā06-19-2017 08:22 AM
"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.
ā06-19-2017 08:44 AM
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
ā06-19-2017 09:09 AM
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 :).
ā06-19-2017 09:18 AM
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.
ā06-19-2017 10:37 AM
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.
ā06-20-2017 08:31 AM
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.
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