Per my previous post ---
[In a full "Nat 0" envrionment with the PIX Functioning as an VLAN ACL Filter]
*) When a packet gets blocked by the default ASA policy -- that of a packet with a source in a lower security level traveling to a higher security level interface, you get a "timed out", or no reponse the default behavior of many firewalls "block", "drop", or "deny" rules.
*) If I don't apply an access-list/access-group combination to an "Internal" interface (one defined by a high security level), the implied behavior is an ACL "permit any any" from traffic headed to a destination on a lower interface. As if an explicity ACL "permit any any" is in place.
*) In that scenario, in order for ICMP (and *ONLY* ICMP traffic) reply traffic
to return back from the lower security level interface at the destionation host,
back to the original sender on the higher level security interface,
I must apply an inbound access-list/
access-group statement matching return traffic.
*) Is this something to do with ASA's automatic stateful/reflexive nature of TCP
v.s. ICMP's stateless? Other firewalls can keep state on ICMP/UDP/GRE/ESP.
*) If I apply access-list/access-group combination to the same internal "higher security" interface in an attempt to restrict access from the higher level security interface/subnet to a lower level security interface/subnet, traffic matching "deny" statements will recieve "Connection Refused" ICMP back (TCP Flag RST from the PIX masquarading as the destination),
which is the OpenBSD PF(4) equiv of a "return-rst" argument to a "block", and what
a non-firewalled host will return to an attempt to open a TCP port to a non-listening Service Port.
from capture:
11:03:32.150565 802.1Q vlan#20 P0 192.168.9.2.23 > 192.168.8.2.1096: R 0:0(0) ack 1397346855 win 65535 <mss 1260,nop,nop,sackOK>
and:
106023: Deny tcp src Customer0:192.168.8.2/1099 dst Management:192.168.9.2/23 by access-group "customer0_2_mgmnt"
*) This behavior is a bit misleading and normally something that you would be able to fine-tune in many firewalls.
*) Also, because Pix only allows application of access-groups "inbound", I am left with this quagmire:
Vlan 11 (interface DMZ, Security0 -- public routable),
Vlan 12 (private management, Security15),
Vlan 2[X], Where
X = Interface:CustomerX (Security50).
- All customer subnets are isolated by the nature of ASA/Same Security Levels; good.
- Nat0 applied to all customer interfaces with
an ACL for *each* matching source that subnet destination the Management subnet
- Granular "inbound" ACLs applied from Customer0 to Management to restrict the
default ASA behavior, overriding the default "permit any" behavior
- Nat1/PAT from Management to DMZ (Via Interface Address):
-- nat (Management) 1 access-list MgmntSubnetToNAT 0 0
- Now I must design a very convuluted Access-list applied "inbound" to the
Management interface to permit:
- ICMP returns to CustomerX interfaces
- Specific TCP/UDP from Management to CustomerX interfaces
- Some kind of permit exemption for all traffic from source Management subnet destined
for a wildcard on DMZ. Luckily, DMZ is a different subnet/ip block, and Cisco ACLs use a match-first-rule-stop-evaluating logic so I can do something like:
Perhaps I would be better off with a Gigabit enabled router acting as an ACL filter? If I don't need NAT, Fixups, Like a 26xx or 28xx router? Something that can take a IPSec enabled IOS image and a VPN acellerator in a WIC port?
The problem is, the Supervisor in my 3550 HSRP Pair (or 65xx MSRP) is simply doing default routing from my DMZ to my WAN subnets.
Unforunately, I only enable IPs on those two VLANs. For security, the VLANs I'm ACL'ing on the PIX are only introduced to Layer 3 *on* the PIX, and only Layer2 on the 3550 Pair.
What I have will work, but it is sub-optimal. I should definately be able to reconfigure "block" ACL behavior in the same way I can with generic IOS.
