ASA 8.3.1 – Smart Tunnel and NAT Changes
I’ll start off with a warning. I’ve been running 8.3.1 on my home 5505 for a few hours now. Not only is this not really enough time for a thorough review, it’s also not the environment to test enterprise-level configurations. There are also a lot of details missing that I just don’t know about yet, so please do some research on your own to figure out what’s going to break if you upgrade your ASA.
If you haven’t heard, Cisco has released version 8.3.1 of their ASA operating system. I’m excited about this for only one reason – Smart Tunnels with tunnel policies.
If you’ve never heard of Smart Tunnels, you’re probably not alone. I don’t know why they’re not more popular than they are, but I dig them. A user connects to a URL, logs in, and a little applet loads on the machine that is used to proxy traffic through the ASA. It doesn’t proxy all your traffic, though; only traffic from applications that you define are sent through the tunnel. There is a huge problem that I can’t stand, though. What if you need to SSH through the firewall and to your local LAN at the same time? The smart tunnel applet doesn’t care or even know what you want to do; it tunnels all the traffic from the application. Not good, eh?
The big change to this in 8.3.1 is the addition of tunnel policies to the smart tunnels. According to the release notes, you can now dictate which connections do and don’t go through the smart tunnel. Now, I can configure the tunnel so that some traffic goes through the ASA to get to the production gear, but other traffic pukes out the NIC normally. I know a lot of users who are going to like not having to log in and out all day.
Note: I may do an article on smart tunnels once everything slows down a bit. It’s a solid way to implement a clientless VPN that doesn’t require administrative access on the machine to run.
The big feature that everyone is talking about, though, is the change to the way NAT is done. Back in the day (that means earlier this morning), if I wanted to configure a static NAT, I’d do something like this to create a static and a service NAT to two different boxes.
firewall(config)#static (inside,outside) 192.0.2.1 192.168.1.100 firewall(config)#static (inside,outside) tcp interface ssh 192.168.1.101 ssh
Now, you create an object and give that object all the attributes. I think Cisco calls this auto-NAT. I have no idea what the auto part means. In our example, we would do something like this.
firewall(config)#object network TESTHOST1 firewall(config-network-object)#host 192.168.1.100 firewall(config-network-object)#nat (inside,outside) static 192.0.2.1 firewall(config)#object network TEST2 firewall(config-network-object)#host 192.168.1.101 firewall(config-network-object)#nat (inside,outside) static interface service tcp ssh ssh
I would say that the configuration is easier to parse with your eyes if the ASA didn’t break up the configuration into two parts. If you were to do a show run and look for our configuration, you would have to look in two places. The first part declares the object name and the host/subnet/IP range for which it’s associated. The next part, which comes after the ACLs, declares the NAT stuff.
object network TESTHOST1 host 192.168.1.100 object network TESTHOST2 host 192.168.1.101 [SNIP a billion lines of ACL] pager lines 24 logging enable logging timestamp logging buffer-size 8192 logging buffered informational logging asdm informational logging host inside x.x.x.x flow-export destination inside x.x.x.x 12345 mtu outside 1500 mtu guests 1500 mtu inside 1500 icmp unreachable rate-limit 1 burst-size 1 icmp permit x.x.x.0 255.255.255.0 inside asdm image disk0:/asdm-631.bin asdm history enable arp timeout 14400 object network TESTHOST1 nat (inside,outside) static 192.0.2.1 object network TESTHOST2 nat (inside,outside) static interface service tcp ssh ssh
It may be simpler to configure, but it’s not simpler to figure out later. I’d rather have single lines of static statements; at least I can use regex on those efficiently.
There is a bright side to the new NAT thing, though. Because the NAT statements are configured in the object, you can now reference the real IP of the host in ACLs instead of the NATted IP. This will help those of us who use firewalls with 488249284 interfaces and that many NATs for each host. If we wanted to allow access to the SSH host in the example, we would write an ACL that allows access to 192.168.1.101 instead of finding the NATted address on that interface and building the rules to that address.
Speaking of ACLs, you can actually create a global access-group. Instead of creating an ACL with rules and an access-group to bind to an interface, you can build one single ACL and configure an access-group with the global directive to basically apply that ACL to all interfaces. A few quick tests show that you can have both interface and global access-group configured simultaneously and that interface ACLs will be executed first. I need to do some more testing to figure out exactly how these work together.
Everyone should upgrade, right? Nope. I don’t ever upgrade to something cool just because it’s cool. I also don’t like to have to buy more hardware to go up a minor revision. Take a look at the the memory requirements for 8.3.1; every model up to the 5510 requires more than the base amount to upgrade. I got lucky since my 5505 has 512MB in it already, but I would hate to have to justify quadrupling (!) the RAM in a 5540 just for some cool features.
Send any rotten tomatoes questions to me.
- Netbox Upgrade Play-by-play - April 25, 2023
- Sending Slack Messages with Python - March 15, 2023
- Using Python Logging to Figure Out What You Did Wrong - February 26, 2023
[…] ASA 8.3.1 – Smart Tunnel and NAT Changes « Aaron’s Worthless Words — Aaron posts some initial thoguhts on ASA 8.3 code. […]
Aaaron thank you for shedding some light to this new ASA release. I just started exploring the new features myself and I totally agree that its a waste of time and money to upgrade to 8.3 at the moment. ASA versions 8.x are so stable that I really don’t see any reason for people to go and buy new memory upgrades just to use the 8.3 release. Anyhow, I will miss the old “global” and “static” commands !!!
I’ll miss those commands, too, Harris. I just realized that I use them to confuse people and establish myself as the expert. With the new simplified syntax, everyone’s going to know how to do it. Heh.
I’m glad to be of service. I’m just glad I was able to get my home 5505 upgraded and let everyone know what’s going on with it.
Back in January I was about to upgrade to the new 8.2(2) that came out. And the release notes indicated that for my ASA5510 I needed to upgrade it from the default 256MB to 512MB DRAM.
So I go through all the trouble of getting a quote from my vendor, getting a purchase order approved, ordering the part, having it shipped, and then work on scheduling a downtime maintenance window. Well here I am 2 months later about to install it this weekend and I see a security vulnerability notice from Cisco that applies to the 8.2(2) version.
I look and see this new 8.3 release has just come out recently as well, so I plan to upgrade directly to that instead. But alas, I find that they yet again bumped up the memory requirement for the ASA5510 to 1GB.
Damn! I just got this 512MB chip, haven’t had a chance to install it, and it’s already insufficient. Thanks a lot Cisco
My ASA is currently on 8.2(2). Let’s just say I don’t upgrade to 8.3.1, because I don’t think it’s worth it. When a security vulnerability is discovered in my current version, which it sounds like from DC there is, then am I forced to upgrade to 8.3.1? Or will they come out with a different version that doesn’t require all hardware upgrade, like 8.2(3)?
Hey, BD. Typically, Cisco will release a fix for a version as long as it’s still within its lifecycle, but I don’t see very many releases for 8.2 on CCO. I would hate to think they would require everyone to upgrade their RAM to fix a security problem, but who knows? 🙁
[…] Top Article by Landings: ASA 8.3.1 – Smart Tunnel and NAT Changes […]
8.2(2) has security vulnerability. if you don’t want to upgrade to 8.3(1), upgrade to the new 8.2(4). It fixes the vulnerability to the previous versions. Cheers!
Hey Aaron, it was quite an impressive article. The basic functionality of the smarttunnel is that it sends all the traffic pertaining to the application to the ASA box. However i have found this doesnt work great when browsers were smart tunneled and with Cisco secure desktop enabled. Not sure if this been addressed in the new version.
So, it all depends on ones requirement for moving for an upgrade. If my issue is addressed im sure i would go for an upgrade.
Good to know, Max. Thanks for the info.