topic What version of ASA software in Network Security

Packet Tracer Output doesn't make sense

krcollab — Tue, 12 Mar 2019 09:36:26 GMT

I have implemented a DMZ and cannot get traffic to flow between the outside and the DMZ (inside to DMZ works). Packet tracer seems to indicate that it's getting unNATed and allowed through the ACL, but then at the end, in phase 6, it says it's being blocked but I can't figure out by what:

The ACL allows SSH traffic from the Vendor's IP to the Public IP of the DMZ server.

packet-tracer input outside tcp Vendor-Company-IP 35000 Server-Public-IP 22

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) Server-Public-IP Server-Private-IP netmask 255.255.255.255
match ip DMZ host Server-Private-IP outside any
static translation to Server-Public-IP
translate_hits = 0, untranslate_hits = 13629
Additional Information:
NAT divert to egress interface DMZ
Untranslate Server-Public-IP/0 to Server-Private-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 Vendor-Company-IP host Server-Public-IP eq ssh
object-group network Server-Company-IP
network-object host Vendor-Company-IP
Additional Information:
Forward Flow based lookup yields rule:
in id=0xac1405e0, priority=12, domain=permit, deny=false
hits=8, user_data=0xa89f5340, cs_id=0x0, flags=0x0, protocol=6
src ip=<Vendor Company IP>, mask=255.255.255.255, port=0
dst ip=Server-Public-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=39108727, 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=2667099, 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=20, 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

What version of ASA software

Marvin Rhoads — Mon, 19 Jun 2017 16:00:11 GMT

What version of ASA software are you running?

The ASA is running 8.2, which

krcollab — Mon, 19 Jun 2017 16:14:41 GMT

The ASA is running 8.2, which may be part of my problem. I'm used to the 8.3 and later conventions.

Hmm. The NAT and ACL syntax

Marvin Rhoads — Mon, 19 Jun 2017 16:19:10 GMT

Hmm. The NAT and ACL syntax looks OK for 8.2.

Phase 6 says it's hitting in implicit deny. Is there perhaps an output ACL on the DMZ interface? If there is, you must explicitly allow the traffic to your server.

There is an outbound ACL on

krcollab — Mon, 19 Jun 2017 16:25:04 GMT

There is an outbound ACL on the DMZ interface (I don't have an inbound one on it).

The ACL, if I set it up correctly, should allow access from the vendor's DMZ server to their servers that are on the inside (VendorX-Inside-Servers) using a specific set of services (VendorX-Services-TCP/UDP). Then it should block access to any RFC1918 addresses other than the ones already specified above it. Then it should allow all other traffic (to grant outbound traffic to the internet).

Here is the DMZ's outbound ACL:

access-list DMZ_outbound line 1 extended permit tcp host VendorX-Private-IP object-group VendorX-Inside-Servers object-group VendorX-Services-TCP
access-list DMZ_outbound line 2 extended permit udp host VendorX-Private-IP object-group VendorX-Inside-Servers object-group VendorX-Services-UDP
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

As I understand what you

Marvin Rhoads — Mon, 19 Jun 2017 16:35:52 GMT

As I understand what you described, the DMZ ACL should be inbound. e.g.:

access-group DMZ_outbound in interface DMZ

(...and perhaps you should rename it accordingly.)

It then affects traffic inbound to the DMZ from hosts in the DMZ. As you have it setup, the outbound ACL affects traffic leaving the ASA's DMZ interface towards hosts in the DMZ. Since the packet-tracer test is not included in that ACL, the traffic is dropped implicitly. You could alternatively add entries for VendorX-Public-IP outbound.

We seldom use outbound ACLs as they affect traffic that has already passed through the ASA. We seldom want to go to the trouble of allowing the traffic in the inbound interface, through the other processes, only to drop it while outbound at the egress interface.