if I then remove the dns-server statment from BLAH-VPN will that group then use the value set in DfltGrpPolicy?
Yes, the dns-server
value it inherits from DfltGrpPolicy
takes over as long as BLAH-VPN
is still defined
I've run into this problem before and there's a couple things happening in this scenario.
First, The Management interface does not play by the same rules as other interfaces on the FW. By default it will not pass or receive traffic from any other interface on the device due to the "Management-Only" setting.
Second, the way that Cisco implements the Management interface causes a routing loop with the ASA. You would like to route all traffic to the management network through the L3 switch on the Inside, but the ASA sees the Management network as directly connected via the Management interface
You would like the traffic to take the following path:
IPS > L3 Switch > ASA Inside > Internet > ASA Outside > L3 Switch > IPS
Unfortunately, the path it is actually taking looks like this:
IPS > L3 Switch > ASA Inside > Internet > ASA Outside > Bit Bucket
Any packet sent from the IPS to the internet is returned to the ASA Outside interface, at which point the routing table is checked and it sees that the management network is directly connected via the Management interface. Since the Management interface will not receive traffic from another interface by default, the bits hit the floor.
Unfortunately, the best way to resolve this issue is to abandon using the Management interface to manage the firewall and instead use the Inside interface. If you remove the IP address of the Management interface (but still keep the port enabled for the IPS module), that will remove the Management network from the ASA routing table. This will allow the traffic to take the correct path back to the L3 switch on the Inside when it returns from the Internet.
I hope this helps
Best Answer
It only looks harmless. :-) In reality, Cisco has a long history of botching the STMP and ESMTP inspection. And honestly, it won't provide any protection from current evolving threats; it doesn't use a dynamic set of rules that can be updated regularly. Email filtering and inspection is best done by a dedicated appliance that's up-to-date.
To my knowledge, there are no knobs on
inspect esmtp
. And this is enough of a reason to never turn it on: