How should a Cisco guy relate to UTM NAT? Scenario & a couple of questions

Hi, Kris, and welcome to the UTM Community!  You're right, there is a culture cliff to climb. [;)]

"I have one of my public IPs bound to OUTSIDE." - The primary IP is bound to a NIC by using it as the IP in the Interface definition.  Other IPs are bound to a NIC by putting Additional Addresses on the Interface as you've noted.  For regular Network definitions, be careful that you don't violate #3 in Rulz.

"... you could also call that Many-To-One SNAT" - The basic difference between SNAT and Masquerading in the UTM is that Masquerading is always the last thing done before the packet leaves.  Note that the Web proxy and SNAT rules take priority, so these packets aren't subject to Masq.  You got that right, too.

Most of us would not use "Any" in a Masq rule.  If you wanted to masq traffic from SSL VPN clients, for example, from their own "SSL VPN" IP, our culture would want 'Internal (Network) -> OUTSIDE' and 'VPN Pool (SSL) -> Outside [SSL VPN]' instead of an SNAT for the VPN clients.

I'm not sure what your "INTERNET ANY" Network Group is doing in your NATs.  It's likely that you only need the "Internet" object in those rules.

Your current configuration will do what you want.  I just wanted to impart a vision of the habits of those of us that have done UTM often and for a long time.

Excellent work and introductory post!

Cheers - Bob

Awesome, thank you Bob!  I have read A LOT of your posts here, including Rulz.  Thank you so much for your advice & insight!

I think I should have included another bit about our infrastructure, all the private networks on the WAN are Ten-Dot.
Everything comes back to the core Layer 3 switch here in my building.  All routes are static and defined in this switch.  Once I'm ready I'll cut over the default route.
Currently:  ip route 0.0.0.0 0.0.0.0  CiscoInsideIP.  When I'm ready to cut over to the UTM, I'll change that to UTMInsideIP

BAlfson said:

The basic difference between SNAT and Masquerading in the UTM is that Masquerading is always the last thing done before the packet leaves.  Note that the Web proxy and SNAT rules take priority, so these packets aren't subject to Masq.  You got that right, too.

Ah, OK.  Good to know.  One thing I'm really looking for is a clear description of UTM's "Order of Operations".  Specifically the processing order for Firewall and Proxy.  EDIT:  Rule #2 explains Ops Order nicely.  Thanks again Bob.  =)

When you say "Web Proxy" are you talking about Webserver Protection?  In the context of SNAT, it would seem so.  Webserver Protection was the first thing I "fell in love" with on the UTM.  I have done reverse proxying from internal web servers to the internet with an intermediate IIS server dedicated to reverse proxying, and it was a complete pain in the ass to configure.  I love UTM's implementation, so easy!

BAlfson said:

Most of us would not use "Any" in a Masq rule.  If you wanted to masq traffic from SSL VPN clients, for example, from their own "SSL VPN" IP, our culture would want 'Internal (Network) -> OUTSIDE' and 'VPN Pool (SSL) -> Outside [SSL VPN]' instead of an SNAT for the VPN clients.

I think I follow you.  As is, everyone on the private WAN accesses the Internet and appears to come from the IP address bound to the OUTSIDE interface.  As you describe above, users on the internal private WAN access the internet from PublicIP-A, but remote users VPN in, then their internet access is piped out via PublicIP-B, which is defined as the SSL-VPN Additional Address on OUTSIDE.  Right?

Aha! I think I know exactly why I will need to tweak my Masqerading config, this is the way I have the Cisco stuff setup now:
Employee computers access the Internet & appear to be coming from PublicIP-A.
Guest Wifi Internet access appears to be coming from PublicIP-B.

BAlfson said:

I'm not sure what your "INTERNET ANY" Network Group is doing in your NATs.  It's likely that you only need the "Internet" object in those rules.

I created that Group so I don't have to worry about my OCD when it comes to IPv6.  =)

Alright, here goes Round Two of adapting a Cisco Brain to UTM.  I'm going to continue to use the object names I created above for my Barracuda Spam Firewall and Exchange MTA/CAS Server.

BARRACUDA-SPAM = private Ten-Dot IP
BARRACUDA-SPAM-NAT = public IP
EXCHANGE-GW1 = private Ten-Dot IP
EXCHANGE-GW1-NAT = public IP

For years I've been doing this sort of thing in Cisco PIX and ASA.  NAT went like this:

On PIX:  static (inside,outside) BARRACUDA-SPAM-NAT BARRACUDA-SPAM netmask 255.255.255.255

On ASA:  nat (inside,outside) source static EXCHANGE-GW1 EXCHANGE-GW1-NAT

Both of these do the same thing - create a pairing between a single public IP and a single private IP, and traffic flows bidirectionally.  Yes, the interface-to-IP address relationship in the PIX looks backwards compared to the ASA, that's just the way it's always been, and PIX is obsolete anyway.   ;)

After the NAT is built, firewall rules need to be created via access-lists, and those access-lists are bound to specific interfaces; AND you also need to specify whether the access-list applies to traffic INBOUND to the interface, or OUTBOUND from the interface.  Years ago my Cisco mentor explained to me the best way to think about interfaces and inbound or outbound "Imagine yourself a tiny little man in the center of the firewall, looking out toward the world.  OUTSIDE-IN means traffic is flowing thru the OUTSIDE interface coming toward you.  OUTSIDE-OUT means traffic is flowing thru the OUTSIDE interface going away from you.  That said, we never did any access-list bindings for out, only in.

It's basically the same on PIX & ASA, so I'll only go thru a single iteration.

My access-list named OUTSIDE-IN defines how to handle traffic coming in on the OUTSIDE interface:

access-list OUTSIDE-IN permit tcp any host BARRACUDA-SPAM-NAT eq smtp
access-list OUTSIDE-IN permit tcp any host EXCHANGE-GW1-NAT eq http
access-list OUTSIDE-IN permit tcp any host EXCHANGE-GW1-NAT eq https
<last rule of every access-list: invisible & implied block everything not defined above>

That access-list then needs to be applied to the outside interface:

access-group OUTSIDE-IN in interface outside

First the access-list name, then the flow direction, then the interface.

If we do not have an access-list bound to the INSIDE interface, EXCHANGE-GW1 and BARRACUDA-SPAM are allowed to access the Internet, and their source IP will appear as EXCHANGE-GW1-NAT & BARRACUDA-SPAM-NAT.  This is because in PIX/ASA, interfaces are assigned security levels.  INSIDE interface = security level 100.  Totally trusted.  OUTSIDE interface = security level 0, The Internet.  By default there is a rule that states "always allow all traffic from a trusted interface / network to less trusted interfaces / networks".

So here it is all together:  NAT public to private IPs, then allow only specific services in from The Internet.  The NATs are bidirectional automatically.

nat (inside,outside) source static EXCHANGE-GW1 EXCHANGE-GW1-NAT
nat (inside,outside) source static BARRACUDA-SPAM BARRACUDA-SPAM-NAT

access-list OUTSIDE-IN permit tcp any host BARRACUDA-SPAM-NAT eq smtp
access-list OUTSIDE-IN permit tcp any host EXCHANGE-GW1-NAT eq http
access-list OUTSIDE-IN permit tcp any host EXCHANGE-GW1-NAT eq https
<last rule of every access-list: invisible & implied block everything not defined above>

access-group OUTSIDE-IN in interface outside

This is a BIG culture change going from Cisco to UTM. 

In Cisco-Land, you always need to be aware of interface and flow direction and configure things specifically with interface and flow direction in mind.

UTM seems to just figure it out for itself, pretty cool! 

So here I am at The Third & Final Round.  I call this "Comfort Level" because I believe it more closely represents how my Cisco Brain is used to doing things.  Based what I wrote above in Round Two, I think this is the ticket to represent the same configuration in UTM.

I created my bi-directional NAT pairings between a single private IP and a single public IP for each host:

Then I created my firewall rules to allow those two hosts outbound Internet access, and allow only specific protocols inbound from The Internet:

So how does that look?

This thread has been a great exercise for me, and I look forward to more comments & advice.

Thanks for reading!

Hi Kris,

how are you finding the UTM compared to the ASA? We have a mixture of both SG310's in failover (and about to do another 2 for load balancing)

We have some Cisco 5505's and 6 Cisco 5520's that we are taking out. We still use Cisco routers and switches which we will continue to do.

Although the UTM can't drill down as far as the ASA etc, it's got some good features and is easy to manage. I sometimes find the firewall rules can get a bit tricky to read once you get to the fifty plus rules as opposed to the ASA in grid form.

One thing I have found over the years is it's essential to name hosts, group them and services etc to keep the rules easy to manage.

But all in all, we like our UTM and use it in conjunction with standalone endpoint protection. It's doing its job nicely.

Hello Louis.  I don't have the UTM in production yet, but very soon.  These forums have been very helpful.

We needed to replace our MS ForeFront TMG server - web surfing control and filtering was our #1 priority.  I really like the higher-layer awareness in the current crop of "next gen" firewalls.  Our ASA-5520 has zero function above Layer 4.  If we had the budget, I'd have a Cisco ASA-5525x with FIREPOWER services.  County Government budgets as they are, we purchased the SG330 instead.

I'm glad we did.

It's been fun learning something so new and completely not-Cisco.  So far I have ZERO complaints on the UTM OS.  The only difficulties I've had with it are my own:  translating what I already know into doing the same thing in UTM, and a bit of struggling to drop "old school" thinking & trust how UTM handles things that I've always had to manually configure or pay close attention to in the past.  =)

We looked at the Firepower but it was early days with people weren't too sure about them at the time.

In terms of value for money, I think the UTM beats them hands down and hardware performance is better too comparing model for model.

We've not had any issues with the UTM yet and it's easily handled our SMTP spam filtering, antivirus, web filtering and reverse proxy etc

It does have some shortcomings eg no GRE and minor things that you miss from the collection of standalone servers that you would normally use. This is more than made up with other items on there as well as ease of use eg QOS etc

Please keep us posted with the progress you make with this as I'm always interested in comments from other leading vendor users.

Great conversation here, guys!

Louis, thanks for sharing.  If you really need a GRE tunnel to a Cisco, there's a command line trick.

Kris, I would do your third post a bit differently - a more elegant, more compact approach.

1. Make your NAT rules use 'Automatic Firewall rules' and delete the now-redundant manual firewall rules.
2. Rather than the "Any" service, make a Services Group that allows only specific ports with your automatic firewall rules.
3. In any case, if you don't want to get rid of 16 and 17, you would need to change "OUTSIDE [...] (Address)" to "INSIDE (Network)" or, better, to "Exchange GW1" and "Barracuda-SPAM" instead.

Was there anything in your second post that I should have responded to?

Cheers - Bob

Just got back from a fun fishing trip, ready to get back at this stuff.   =)

I understand 1 & 2 - and I think I'm going to go that way.  So #3 is moot.

On the second post - no, that was just a write up on how I'm thinking thru these things - it helped me to write it and I hope it might help someone else someday when they read it.

Thanks again Bob!

Well wait a second.  I'm still not quite clear on SNAT and Masquerade public IPs.

Say my public Masqerading IP is 64.20.192.1 -- all outbound traffic to the internet from my private network appears to come from this IP address.

If I don't define the SNATs for EXCHANGE-GW1 & BARRACUDA-SPAM as above, will they appear to come from that IP address too when they talk to the Internet?

I'm guessing here:

1.  No SNAT 

Inside Server 10.10.10.1 establishes outbound SMTP with mail.google.com to deliver a message to someone@gmail.com

mail.google.com sees Inside Server's source IP as the Masqerading IP -- 64.20.192.1

2.  Dedicated SNAT 10.10.10.1 --> 64.20.192.2

Inside Server 10.10.10.1 establishes outbound SMTP with mail.google.com to deliver a message to someone@gmail.com

mail.google.com sees Inside Server's source IP as the IP configured in SNAT -- 64.20.192.2

Do I understand this correctly?

Thanks!