Hello, One question I have seen asked repeatedly is "How can I add an ACL to allow *some* traffic from one security interface to a higher one, while still allowing (the implicit rule for) all traffic to lower ones?" The answer is always that you can't, and that explicit permit statements need to be added. The question I have is, how can ACLs be kept neat and manageable with such a limitation? I'd like to illustrate my problem by example. If I have: outside, security level 0 dmz, security level 50, subnet 192.168.101.0/24 inside, security level 100 subnet 192.168.201.0/24 By default inside can access everything, dmz can access outside only, and outside nothing. If I decide to allow traffic for DNS, say, from dmz to inside, I create an inbound ACL on dmz: access-list dmz-in extended permit tcp any host 192.168.201.50 eq domain How can I nicely allow all traffic to outside on the ACL? I could add a deny to inside, and then permit all... access-list dmz-in extended permit tcp any host 192.168.201.50 eq domain access-list dmz-in extended deny ip any 192.168.201.0 255.255.255.0 access-list dmz-in extended permit ip any any That works; but then if I add more interfaces later (e.g. database with security level 75) then I've got to add similar exceptions. (And since I will probably need to allow access to the DNS server from database also, the problem is compunded, and multiplied each time I add a new interface. We're creating a VLAN for each customer and most will be routable without NAT.) I would love it if there was a way to say "permit from dmz to outbound". Am I missing something, or a way of implementing that will be much neater? Or can anyone provide an example that shows better configuration? Thanks, Bob McChesney ... View more

Hello, I am having an issue where ICMP "Unreachable, need to fragment" packets sent by the ASA are not delivered, apparently due to asymmetric NAT rules, when communicating over IPsec VPN. The device is a new Cisco ASA 5510 with Security Plus, running version 8.2(5). The ASA is in a data centre, and I have an IPsec tunnel between it and a router in my office. The ASA has 'inside' and 'outside' interfaces, and dynamic NAT has been enabled for the inside subnet, and a NAT bypass access-list created to exclude traffic from inside to my office subnet. NAT and routing are all working fine (i.e. I can create connections between office subnet and 'inside' subnet, and also 'inside' can connect to the Internet and is correctly NATed). Problems start when a device on 'inside' tries to send packets too large with DF bit set. For example, if I access a management website on a server, the connection is made correctly but then the server tries to send packets too large. The ASA should send an ICMP message "Unreachable, need to fragment", so that the server knows to resend with smaller packets, but it doesn't. However, if I turn off NAT, it does! The following warnings are logged: "PMTU-D packet 1420 bytes greater than effective mtu 1386, dest_addr=192.168.88.151, src_address=192.168.99.52, prot=TCP" "Asymmetric NAT rules matched for forward and reverse flows; Connection for icmp src outside:192.168.99.1 dst inside:192.168.99.52 (type 3, code 4) denied due to NAT reverse path failure" (192.168.88.151 is the querying PC, 192.168.99.52 is the server being queried, 192.168.99.1 is the ASA inside address.) Does anyone know how to resolve this? I think it's a little odd that the warning shows "outside:192.168.99.1" as that's the inside IP address of the ASA. My NAT configuration: access-list inside-nat-bypass extended permit ip 192.168.99.0 255.255.255.0 192.168.88.0 255.255.255.0 global (outside) 101 interface nat (inside) 0 access-list inside-nat-bypass nat (inside) 101 192.168.99.0 255.255.255.0 Again, the above works (I can access the Internet from 'inside' and I can communicate fine between 'inside' and my office); it is just that the ICMP "need to fragment" packet doesn't get sent, and so PMTU-D doesn't work. Finally, when I run a packet capture in ASDM, I can see the ASA is creating the packets, but they only appear on "egress: outside", not "ingress: management". However, when NAT is turned off, the packets appear in both. I believe therefore that the packets are failing a rpf-check, which is odd as they're from the ASA itself. Suggestions very welcome! I can provide configuration if required. Thanks, Bob McChesney ... View more