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

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! 

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!

Yes, SNAT takes priority over masquerading.

Cheers - Bob