Leave the physical port you are using as the untagged VLAN. You can direct that traffic to a VLAN# on your switch by setting the Native VLAN the VLAN# you want that traffic to be on.
Then for every new VLAN you are adding to your ASA, make that a sub interface.
I don't have an ASA to validate this code, but it will look something like this:
interface gig0/0
nameif ORIGINAL-NAMEIF
security-level 100
interface gig0/0.20
vlan 20
nameif NEW-VLAN-2
security-level 20
interface gig0/0.30
vlan 30
nameif NEW-VLAN-3
security-level 30
etc. It should allow you to add new sub interfaces without making any changes to your original interface. The "root" interface doesn't include a VLAN tag, so that traffic is unchanged.
You can run it this way indefinitely, or change it so everything is using VLAN tags at a later date when its more convenient for you to bring the network down.
Everything being done by the ESMTP inspection is related to the information being exchanged between hosts. It is not related to NAT, ACLs, IPs or interfaces the client and server reside on with one exception: One of the interfaces the traffic is traversing has the inspection rule turned on or it is globally turned on for all interfaces.
The information being sent between hosts will be modified if it doesn't match the criteria the ASA expects or if it sends information the ASA wants to mask between parties.
More info can be found in the config guide.
Reason for 220 Banner Modification
Another security feature used by these devices is SMTP banner modification. In order to hide the type and version of the protected mail server, some devices will obscure all but the 220 portion of the banner that is required for communication.
The banner will often appear similar to:
220*************
Part of the information being hidden is the ESMTP advertisement in the banner. When this advertisement is removed, a sending server will not be aware that ESMTP commands are accepted.
Source
You can also disable just the banner modification.
policy-map type inspect esmtp new_estmp_inspect_map
parameters
no mask-banner
policy-map global-policy
class class-default
inspect esmtp new_esmtp_inspect_map
service-policy global-policy global
Source.
Reason for Replies
The ASA only supports 15 SMTP commands, any others will return the errors you are seeing. The second SMTP server (1.2.3.4) is using commands the ASA doesn't support or they are improperly formatted.
ESMTP application inspection adds support for extended SMTP commands, including AUTH, EHLO, ETRN, HELP, SAML, SEND, SOML, STARTTLS, and VRFY. Along with the support for seven RFC 821 commands (DATA, HELO, MAIL, NOOP, QUIT, RCPT, and RSET), the ASA supports a total of 15 SMTP commands. Other extended SMTP commands, such as ATRN, ONEX, VERB, and CHUNKING, and private extensions are not supported. Unsupported commands are translated into Xs, which are rejected by the internal server. This results in a message such as "500 Command unknown: 'XXX'." Incomplete commands are discarded.
Source
To verify, I recommend using a packet sniffer between the ASA and 1.2.3.4 to see which commands are being returned.
Best Answer
Unfortunately, Cisco has not given us a precise, one-line way to remove a single object or object-group. This is something that may come in time as the ASA code continues to mature and the ASA's themselves get more CPU resources. The original ASA line was pathetically underpowered in the CPU department. Your 5505, for example, was first released in 2006 and has a
Pentium 4 Celeron 2000 MHz
!An intelligent, recursive search through the configuration to remove an object or object-group would require CPU resources that just weren't there when the software was being written. Especially not if they had to come at the cost of processing traffic. I work daily on ASAs with thousands of objects and and tens of thousands of ACL lines, and I wish for this feature every day.
For now we're left with a manual search process, similar to what I demonstrate below. This process can certainly be automated in Python, for example, however I give the manual process to illustrate the logic involved.
For this example, I have the following object, object-group, and ACL:
If I want to remove
TEST-OBJECT
and any references to it, as you found out, I can't simply do the following:I now have to search for all instances of the object and remove those lines.
First, I look at the running-configuration for the object name and for the string
p n
, which matchesobject-group network
. This gives us the names of all network object-groups, and we now have to simply look for instances ofTEST-OBJECT
, then go up to find what object-group it is a member of:So we know we need to remove
TEST-OBJECT
from theTESTING-OBJECT-GROUP
object group, and remove a single ACL line:Finally we can successfully remove the object itself and validate that it is gone: