topic Re: NAT issue across interfaces in Network Security

NAT issue across interfaces

WStoffel1 — Tue, 12 Mar 2019 00:42:37 GMT

First off, Thanks everyone for all the advice all the time!

I keep finding small NAT/ACL issues with the attached config I'm having great difficulty overcoming. More importantly it seems one fix you all help me out with, doesn't, in my mind anyway, translate to the next issue...so here goes.

I have an Exchange server that sits behind sub-int 180. There's another Exchange server that sits behind sub-int 133 and I need to be able to send email from 192.168.180.26 to 192.168.133.6. And likewise, back in the other direction.

To start with all of these interfaces had a sec level of 90. The reason 133 is now 95 was to pass traffic from higher to lower and access a web server behind sub-int 146, along with this NAT:

static (AUD,Franklin) 192.168.133.0 192.168.133.0 netmask 255.255.255.0 (and the AUD dns server is configured to use the local address of the web server).

I only mention this in case there's something with the 133 interface that should be changed.

The packet trace from 180 to 133 follows:

packet-tracer input Exchange tcp 192.168.180.26 32000 192.168.133.6 80

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found no matching flow, creating a new flow

Phase: 3

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in 192.168.133.0 255.255.255.0 AUD

Phase: 4

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Result:

input-interface: Exchange

input-status: up

input-line-status: up

output-interface: audubon

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

Clearly I'm trying to access a higher security level interface.

I have done a few things to troubleshoot, namely lowering int 133, 146, 180 security level's by 5 and I end up with a NATing problem, I'm thinking I don't want to muddy up this discussion with TOO much info...Just say the word and I'll throw those changes and the resulting packet trace

Re: NAT issue across interfaces

Jouni Forss — Wed, 02 Jan 2013 17:56:56 GMT

Hi,

I guess the only 2 options would be to either change security-levels (with the risk of causing problems with something else) or just by configuring Exchange interface an ACL so it can connect to networks behind a more secure interface.

If you configure an ACL, you will have to make sure to allow all the traffic needed since "security-level" will no more determine the allowed connections but instead it will be decided by the ACL you have just configured.

You do seem to have a huge NAT configuration and its pretty hard to go through without having the help of actually going through it through the ASA CLI

- Jouni

Re: NAT issue across interfaces

Jouni Forss — Wed, 02 Jan 2013 18:09:10 GMT

If you happen to make an ACL and still want to apply rules that follow the logic of the security-levels I guess you could try the following

Configure an "object-group network
"
- include all the destination networks under this object-group which are located behind interface with higher security-level than the interface you are gonna make the ACL for
Configure the ACL configuration with the following lines
- access-list remark Deny all Connections to Higher Security Level networks
- access-list deny ip any object-group
- access-list remark Allow all other traffic
- access-list permit ip any

The above ACL coupled with the object-group created would still block traffic to higher security-level networks but allow all other traffic.

Its a totally different matter how bloated the configuration will become unless you come up with a plan to make the network setup simpler.

I have personally not used "security-level" value that much to determine what traffic can be initiated. I have usually just configured ACL for each interface to avoid playing around with the "security-levels"

Your configuration is otherwise pretty simple other than for the Static NATs that you use to NAT local addresses to public IP addresses towards other LAN networks. This is I guess to avoid doing changes to DNS configurations? Then again as long as everyone behind the ASA uses public DNS, you can let the ASA rewrite the DNS reply messages by adding the "dns" parateter to the LAN -> OUTSIDE Static NAT configuration for the servers.

- Jouni

NAT issue across interfaces

WStoffel1 — Wed, 02 Jan 2013 21:39:01 GMT

To answer a few of your questions first, these interfaces are all customers. With their own unique LAN behind each interface. The static nats are those clients public facing web servers...which is public address provided by us, natted to their own local address.

Most of the time the LAN behind an interface is a Microsoft AD domain, so it's using the local domain controller for DNS.

Hence the dns parameter doesn't really buy me much. With few exceptions they are rarely using a public DNS server so the reqeust doesn't cross the ASA.

The AUD interface is a client that access a Franklin web server. AUD has the Franklin zone on their Microsoft DNS server, with the local addressing and that nat mentioned above. The only way I could get the combination to work was raise the interface to 95.

So...

I will attempt the ACL route after hours and post my results

Thank you!

NAT issue across interfaces

Jouni Forss — Wed, 02 Jan 2013 21:45:47 GMT

Hi,

If you can make simply enough basic ACL for every customer interface I guess you could go with the ACL route and simply attach every interface their own ACL. After this you wont have to worry about security-levels anymore.

Naturally you will have to modify the ACLs abit but I'd imagine the bulk of the work would be making the initial configurations and modifying the configurations as needed would still be a small problem.

Each customer interface ACL would probably have to start out with a Deny statement that blocks all traffic to other networks which could be grouped under object-group. (Same object-group for all interface ACLs) If there is traffic between customer interfaces you would naturally just add permitting statements for the wanted service (IP/TCP/UDP and port if TCP or UDP) at the very top of the ACL before the Deny statement.

- Jouni

NAT issue across interfaces

WStoffel1 — Thu, 03 Jan 2013 21:24:07 GMT

OK, so I need traffic to go from 192.168.180.0/24 to 192.168.133.0/24

I was able to follow this:

Configure an "object-group network
"
- include all the destination networks under this object-group which are located behind interface with higher security-level than the interface you are gonna make the ACL for
Configure the ACL configuration with the following lines
- access-list remark Deny all Connections to Higher Security Level networks
- access-list deny ip any object-group
- access-list remark Allow all other traffic
- access-list permit ip any

Which in my config I entered as:

object-group network Test_Group

network-object 192.168.133.0 255.255.255.0

access-list Testing1 remark Deny all Connections to Higher Security Level networks

access-list Testing1 deny ip any object-group Test_Group

access-list Testing1 remark Allow all other traffic

access-list Testing1 permit ip 192.168.180.0 255.255.255.0 any

Which in my mind made sense

packet-tracer input Exchange tcp 192.168.180.26 32000 192.168.133.6 80

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found no matching flow, creating a new flow

Phase: 3

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in 192.168.133.0 255.255.255.0 AUD

Phase: 4

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Result:

input-interface: Exchange

input-status: up

input-line-status: up

output-interface: AUD

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

Re: NAT issue across interfaces

Jouni Forss — Thu, 03 Jan 2013 21:29:29 GMT

Hi,

Have you attached the ACL to the interface?

access-group Testing1 in interface Exchange

- Jouni

Re: NAT issue across interfaces

WStoffel1 — Fri, 04 Jan 2013 14:37:02 GMT

Clearly I had not, hahahaa.

I'm going to attach the packet tracers, since I have a few now. But I did manage to pass traffic eventually from my lower security interface (Exchange) to my higher (AUD)!!!

I'm just showing my steps in case i did something completely wrong, but still ended up making it work.

In particular I had to remove access-list Testing1 deny ip any object-group Test_Group, see below:

Once i applied the acl to Exchange I was still getting dropped due to a configured rule:

Phase: 4

Type: ACCESS-LIST

Subtype: log

Result: DROP

Config:

access-group Testing1 in interface Exchange

access-list Testing1 extended deny ip any object-group Test_Group

access-list Testing1 remark Allow all other traffic

object-group network Test_Group

network-object 192.168.133.0 255.255.255.0

Additional Information:

So i removed the deny ip any at the start of the Testing1 acl (access-list Testing1 deny ip any object-group Test_Group)

and got the following (progress):

Phase: 8

Type: NAT

Subtype: rpf-check

Result: DROP

Config:

nat (AUD) 1 192.168.133.0 255.255.255.0

match ip AUD 192.168.133.0 255.255.255.0 Exchange any

dynamic translation to pool 1 (No matching global)

translate_hits = 0, untranslate_hits = 0

Additional Information:

So I added static (Exchange,AUD) 192.168.180.0 192.168.180.0 netmask 255.255.255.0

That got me to:

Phase: 9

Type: NAT

Subtype: rpf-check

Result: DROP

Config:

nat (AUD) 1 192.168.133.0 255.255.255.0

match ip AUD 192.168.133.0 255.255.255.0 Exchange any

dynamic translation to pool 1 (No matching global)

translate_hits = 0, untranslate_hits = 0

Additional Information:

Which in my mind the translation coming back was not correct and added static (AUD,Exchange) 192.168.133.0 192.168.133.0 netmask 255.255.255.0

Resulting in:

Phase: 13

Type: ROUTE-LOOKUP

Subtype: output and adjacency

Result: ALLOW

Config:

Additional Information:

found next-hop 192.168.133.6 using egress ifc AUD

adjacency Active

AUD is my higher security interface!

Nothing else seems to be broken.

My only concern is did I do the translations appropriately?

By removing access-list Testing1 deny ip any object-group Test_Group am i creating a giant hole in my firewall?

See attached....

Thank you so much!!!!!

To sum up, here's the config i added:

access-list Testing1 permit ip 192.168.180.0 255.255.255.0 any

access-group Testing1 in interface Exchange

static (Exchange,AUD) 192.168.180.0 192.168.180.0 netmask 255.255.255.0

static (AUD,Exchange) 192.168.133.0 192.168.133.0 netmask 255.255.255.0

Re: NAT issue across interfaces

Jouni Forss — Fri, 04 Jan 2013 14:52:25 GMT

Hi,

Some things

It cant see what your object-group Test_Group containts but I would suspect that you have actually added the AUD network in this group, which you shouldnt have. Though now looking at what I have written to you I have probably not written it in the clearest way.
- What you could do regarding this is to keep the "deny ip any object-group Test_Group" statement BUT add your "access-list Testing1 line 1 permit tcp 192.168.180.0 255.255.255.0 192.168.133.6 eq 80". This would first allow the connection you need THEN deny all rest to your local networks and THEN allow everything else (which would equal traffic headed to outside)

Access-list could look like this

access-list remark Allow specific Traffic to other local networks
access-list permit tcp 192.168.180.0 255.255.255.0 host 192.168.133.6 eq 80
access-list remark Deny all Connections to Higher Security Level networks
access-list deny ip any object-group
access-list remark Allow all other traffic
access-list permit ip any

I think the problem you had with the Static NAT is that you only need the "(AUD,Exchange)" line. To my understanding these type of statics are always done as the higher security-level interface as the source and the lower as the destination
- static (AUD,Exchange) 192.168.133.0 192.168.133.0 netmask 255.255.255.0
- The above command should be bidirectional, as in handle connections from either network/interface

Please rate if the information has been helpfull And naturally ask more if needed

- Jouni

Re: NAT issue across interfaces

WStoffel1 — Fri, 04 Jan 2013 15:22:42 GMT

Test_Group DOES contain the AUD network, and nothing else! I had a hard time with that one, but yeah, i couldn't grasp where you were going with it, and just applied it Well, just applied it as I was interpreting it...

I'll go back and change the ACL to start. Then post back. I have to work on a bunch of other things today so unfortunately it's not going to be till late this afternoon...possibly this weekend.

But to just back up for a minute, could you possibly clarify what your original intent was for the "object group network "

Maybe i'm missing something.

Thank you again!

Re: NAT issue across interfaces

Jouni Forss — Fri, 04 Jan 2013 15:44:31 GMT

Hi,

So basically when we consider your setup before you made any changes to your firewall configurations, almost all of your interfaces lacked any "access-list" configurations and only "security-level" value decided what traffic was allowed.

This again lead to the fact that Exchange (90) couldnt not access anything on AUD (95)

Now when we consider that you configure an ACL to an interface (Exchange) its "security-level" looses its meaning while controlling traffic.

My idea was to build the new ACL rules for the Exchange traffic with the same logic than was with the "security-level" in place.

This would require configuring the new ACL in the following way

It should allow the traffic you are going to attempt
It should block all traffic to interfaces/networks which have higher "security-level" than Exchange
It should allow traffic to all lower "security-level" interfaces/networks

The object-group is supposed to be an "object-group" that contains all the networks related to the higher "security-level" interfaces. The "permit ip any" is supposed to allow all other traffic.

What I did forget to write in my above answers was that you need to make an ACL rule at the very top of the new ACL that allows the TCP/80 connection you are attempting from Exchange to AUD. If you didnt the connection would naturally be dropped by the "deny ip any object-group " line.

So to I would have entered/added the following configurations

Define object-group that contains all the networks behind more secure interfaces

object-group network EXCHANGE-BLOCKED-NETWORKS

description Blocked Destination Networks for Exchange

network-object 172.16.0.0 255.255.254.0

network-object 172.16.2.0 255.255.254.0

network-object 172.16.4.0 255.255.254.0

network-object 172.16.8.0 255.255.254.0

network-object 192.168.31.0 255.255.255.0

network-object 192.168.35.0 255.255.255.0

network-object 192.168.42.0 255.255.255.0

network-object 192.168.112.0 255.255.255.0

network-object 192.168.220.15 255.255.255.255

network-object 192.168.220.16 255.255.255.255

network-object 192.168.220.17 255.255.255.255

network-object 192.168.220.18 255.255.255.255

network-object 192.168.221.15 255.255.255.255

network-object 192.168.222.15 255.255.255.255

network-object 192.168.224.15 255.255.255.255

network-object 192.168.225.15 255.255.255.255

network-object 192.168.226.15 255.255.255.255

network-object 192.168.105.0 255.255.254.0

network-object 192.168.139.0 255.255.255.0

network-object 192.168.133.0 255.255.255.0

Configure the ACL

Allow the TCP/80 traffic
Deny all other traffic to more secure networks (based on the object-group created before)
Allow all traffic which will permit traffic to all less secure interfaces (outside + local)

access-list EXCHANGE-IN remark Allow specific Traffic to other local networks

access-list EXCHANGE-IN permit tcp 192.168.180.0 255.255.255.0 host 192.168.133.6 eq 80

access-list EXCHANGE-IN remark Deny all Connections to Higher Security Level networks

access-list EXCHANGE-IN deny ip any object-group EXCHANGE-BLOCKED-NETWORKS

access-list EXCHANGE-IN remark Allow all other traffic

access-list EXCHANGE-IN permit ip 192.168.180.0 255.255.255.0 any

Attach the ACL to interface

Controls traffic incoming to interface Exchange with the "in" parameter

access-group EXCHANGE-IN in interface Exchange

Configure Static NAT to allow connection with the original IP addresses bidirectionally

static (AUD,Exchange) 192.168.133.0 192.168.133.0 netmask 255.255.255.0

EDIT: Gah! I hate how the site changes rows for the ACL lines that are long

- Jouni

Re: NAT issue across interfaces

WStoffel1 — Fri, 04 Jan 2013 21:13:00 GMT

Wow. I mean WOW! I was expecting a quick description and I got the motherload! I wasn't even coming close this, you're on such a higher level than me. Thank you.

I ripped out the config from earlier and I'm going to have at this.

Now I'm starting to wonder if changing security levels wasn't the way to go to fix my earlier problems and I should have configured access lists on the interfaces instead. It seems logical now. But I inherited this config so I just keep plugging along with it.

THANK YOU!

Re: NAT issue across interfaces

WStoffel1 — Fri, 04 Jan 2013 21:25:07 GMT

And actually my LIT interface is at 95 for no reason now that i look at it, so that one i can set back to 90 like the rest.

Certainly making the above config a little smaller.

Re: NAT issue across interfaces

WStoffel1 — Sat, 05 Jan 2013 13:21:17 GMT

You my friend are a firewall GURU!

Thank you!

NAT issue across interfaces

Jouni Forss — Sat, 05 Jan 2013 13:26:42 GMT

Glad to be of help

- Jouni