Just wondering if I am the only idiot out there who took a look at the 8.3 NAT changes and thinks these changes are not really necessary, make the config much too big and in general cause too much confusion. In addition, the 8.3 NAT configuration looks like it assumes nat-control is on, so in environment where nat control is predominantly not used, the config gets bigger, because of all the non nat exceptions that have to be made. IOW, heavy nat config may translate to a more digestible config. But heavy no-nat config may translate to a bloated config.
Problems I see:
-I don’t want to go around and upgrade memory in all my firewalls just for a .X release.
-Config become much too bloated in heavy non-nat environment (and possible nat environment). In one example, config went from 50-60kb -> 150kb! It’s also 'difficult' on the eyes!
-Replacing inside IP addresses in a outside interface ACL is non-intuitive for a L3 guy. Why would I want to let a public host firewall through to a private IP address on my outside interface?!?!
-no Nat-control” command is gone? Does this mean I have to except every no-nat item? What is going to happen to predominately internal firewall configs? Can I turn off Nat globally?
HELP! My first response is that I hope Cisco supports 8.2 for a long time, or at least has a config "switch" to keep NAT working the old way!
I would suggest to voice your concerns towards your local SE re. supportability etc.
I'm afraid I cannot make a stetment about what I feel about the changes that would not be interpreted the wrong way.
So I'll just stick to the facts.
- NAT control is now deprecated.You are not required to have nat statments, but same thing as before applied - traffic from lower sec interface to higher sec interface does require existing xlate.
- General intention was to make NAT more flexible (achieved, previous NAT was missing quite a few things)
- The general intention was to make NAT managable via ASDM - and you can see that one line in ASDM translates to as many as 8 lines in CLI.
- There have been also changes done to proxy arp that some might find interesting.
Re 8.2 - please note that there is no plan to either introduce new webvpn features (smart tunneling wise and browser support wise) that were introduced in 8.3.
To comment a little bit on this:
I understand there is a learning curve with this that people will need to go through for the 8.3 changes. But I believe in the long run the changes will work to our benefit.
The "real ip" will simplify your ACL in the long run since you don't need to change ACL and nat when you change your translations. You also don't need to remember the translated ip of the host when setting up ACLs.
The nat statements have been simplified and can be run more "on the fly". The syntax is the same for all cases (nat statements, no nat 0, statics, nat with acls etc). As long as you name your objects properly I believe nat has benefits compared to the old nat. I understand it can be a little harder to troublehsoot and get used to the new syntax and that is where the learning curve comes in.
Keep in mind that no nat control is enforced by default now, so you don't need to nat exempt everything.
The are also some nice feature like the global ACL and the Smart Call Home that I believe will be liked more and more in the future.
I hope that as soon as you get passed the getting familiar and learning part, 8.3 will be liked a lot.
8.2 will be supported for a long time, so that should not be a concern.
Hi..I agree 8.3 have some dramatic changes compared to earlier 8.x series, but as Marcin and Panos commented, with playing around a bit more on this you will start liking it..at least I did.....and break as much as you can coz unless we break we wont know how to built...but do that in lab not in productions :-)
a)ACLs have private IPs now which means that in case if you have any ISP cutover or a change in public block then the access-list applied on outside will remain as it is
b)The nat-control command is deprecated...here is the link that tells you the equivalent of nat-control
Hope it answers some of your questions
the more i think about this private Ip address on the external public interface ACL, the more I don't like it. Outside of being non-intuitive:
-sometime i put in a "deny any 10.0.0.0 /8" in front of all the real "allow" rules. if my internal host is running on a 10.0.0.0 number, i have to exclude this now by default or put in the deny 10.0.0.0 / after all the other real ACL's.
-what if I have a host 1 hop away (RFC 1918 routing doesn't stop packet) from my firewall on the outside, can it actually get through the firewall using the 10.0.0.0 number running the inside host, by virtue of this rule?
-haven't though through yet what this means for the AIP-SSM IPS sensor, but it may also choke and die, or require reconfigure.
-if I my ACL's are audited, the auditor will freak when he sees this rule on the external interface. then I will have to tell them, well this is asa 8.3 and its "special." this will start opening up a can of worms and further inquiries; or I will have to search and replace all my "special" ACL's.
really, this is almost too much black-box voodo going on in the background. We just need to see the ACL's like they are intended to be at L3. I do not want to see some fake or translated number and then realize the ASA is doing something in the background.
So can I deploy the new nat functionality without munging the public interface ACL's???
Your concerns are of course valid. And don't think the changes were taken lightly internally, there was a serious discussion around it. And yes probably if you and me set down we could find our own (perhaps better - in the sense that it would suit the two of us better) way of doing it.
You need to look at the new setup in a way that does not exist (yet?) anywhere in Cisco world, but it already exists elsewhere (other vendors implements ACLs in a similar way).
Re your first two points, nothing that unicast RPF will not be able to handle, provided routing table is OK ;-)
All chnages should be mostly transparent to AIP.
Also old ACLs will be automatically converted when moving from older software versions (please note that are bugs in this process that we are aware of, fixed by 8.3.2).
All in all we were used to certain things being certain way, it will take all of us (myself included) to grow accustomed to changed and appreciate new possibilities.
To add to Marcin's suggestions: If you are audited and they give you grief because they see 10.0.0.0/8 in the config don't let them. It is a matter of what traffic is allowed to flow and not how it looks to the eye
I agree with you 110%. I like Cisco because it does not change its commands so frequently and dramatically like MS does. However, this ASA 8.3 just gave me a shock. I am working on different kind of FW such as ASA, CheckPoint and Juniper. None of them is so confusion regarding to configuring the NAT feature.
Cisco engineers should remember that features are only one part of a product. Consistence is also a part of a product, especially for a widely used and mature product. Many of ASA FW are deployed in the important production environments. There is no much downtime for users to migrate such big change. In addition, a lot of customers do not have a luxury testing environment to test this migration process.
Actually, CLI is just an interface for users to configure the ASA. If Cisco engineer would like to add more features, those features can be easily embedded into the existing commands or by adding a few more extra options or commands. Sometimes, changes are good thing. Sometimes they are bad thing. I really believe that this new 8.3 is not a good example of changes.
I think that this new 8.3 may come from some Cisco "Geeks" in the lab who like to see the complex and "new cool" commands without understanding the impact to the users and market. I doudted Cisco did any marketing research and user survey before pushing out this 8.3. If Cisco did, it would find out that it made a mistake..
Yes, there are other vendors which use different ways to configure ACL and security rules. However, Cisco is the market leader in FW. It should lead the trend. Does it mean that now Cisco has to follow others to use all Linux commands to configure devices. If Cisco likes to push customers to use its ASDM to configure ASA, please check the CheckPoint GUI client. It is the best. It is simple and easy to use. Specially, CheckPoint smart tracker gives users the clearest way to read log and troubleshoot rather than 2 or 3 entries for each connection like ASDM does. CheckPoint Smart Tracker can also pull the log files so that users can easily trace something back. However, ASDM can only keep very limited the log info. There are a lot of areas where Cisco can improve ASDM more user friendly and useable rather than change the all NAT in the CLI to match ASDM.
As a user, I like to learn the new features of Cisco devices, but I do not want to spend time to learn the new format of old features.
I hope Cisco engineer can listen to users feedback and learn the lesson. I was just back from CiscoLive. So far I have not heard any good feedbacks from any users I knew about this 8.3.
Do not take me wrong. I like Cisco stuff. I have used them in the past over 12 years. This is why I give my honest feedback to Cisco.
Thank you for the feedback Sean. We will take it back home and use it.
I see your points.
I hope that in the long run you will like the CLI changes in 8.3.