topic New twist to an old issue in Network Security

New twist to an old issue

WStoffel1 — Tue, 12 Mar 2019 00:41:50 GMT

I had a very similar issue (NAT/routing issue from one subinterface to another)...and i used this resolution for another problem between two interfaces.

In the attached config you'll see my Franklin interface 3.146 which has a web server behind it. Users behind my AUD interface on 3.133 were not able to get to the web server. Traffic was always supposed to go from AUD to Franklin, so:

1.Raised security level on AUD to 95 (Franklin is at 90)

2.Added the appropriate DNS zone to the AUD internal DNS server for the website, using the local IP addresse

3.Added a static nat between the two interfaces

And I believe that was it and it worked perfectly!

Problem now, i have traffic that's sourced at Franklin and they need to access an email server behind AUD. It doesn't work. Any ideas?

Thanks in advance as always!!!

New twist to an old issue

Jouni Forss — Fri, 28 Dec 2012 16:54:11 GMT

Hi,

Have you tried using the "packet-tracer" command to simulate the connection attempt and see what the output is?

If you can take the output of the "packet-tracer" command, copy/paste it here.

- Jouni

Re: New twist to an old issue

WStoffel1 — Fri, 28 Dec 2012 17:28:05 GMT

Of course:

packet-tracer input Franklin tcp 192.168.146.10 32000 192.168.133.10

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: UN-NAT

Subtype: static

Result: ALLOW

Config:

static (AUD,Franklin) 192.168.133.0 192.168.133.0 netmask 255.255.255 .0

match ip AUD 192.168.133.0 255.255.255.0 Franklin any

static translation to 192.168.133.0

translate_hits = 17, untranslate_hits = 1

Additional Information:

NAT divert to egress interface AUD

Untranslate 192.168.133.0/0 to 192.168.133.0/0 using netmask 255.255.255.0

Phase: 4

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Result:

input-interface: Franklin

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

The configured rule is of course the implicit deny from a lower security interface to a higher, correct?

I attached the packet trace in the other direction for what's currently working...in case it's any help..

New twist to an old issue

Jouni Forss — Fri, 28 Dec 2012 17:32:25 GMT

Ah,

It does seem you have ACL attached to only 2 interfaces and neither of them is related to this connection attempt.

I guess you need to configure an appropriate ACL for the Franklin interface to allow the traffic in this direction since the security-level is blocking the connection attempts.

- Jouni

Re: New twist to an old issue

Jouni Forss — Fri, 28 Dec 2012 17:37:32 GMT

Also,

If you want to build the ACL in a way that it still follows the logic of your Security-level setup I guess you should first block some traffic on the ACL and then allow all the rest of the traffic.

It seems the following interfaces have higher Security-level than Franklin

AUD
Little
LV

You could for example build the ACL in the following way.

First configure ACL statements that allow the traffic you are attempting from Franklin to AUD
Second configure ACL statements that block all the (rest) traffic from Franklin to AUD, Little and LV networks
Third configure ACL statement that allow all rest of the traffic

To my understanding with the above way you would still limit traffic from Franklin from entering AUD,Little and LV (like it was to my understanding with the security-levels alone controlling the traffic) BUT still allow the specific connections from Franklin to AUD server. If you just confired an ACL that permitted all traffic it would make it possible for Franklin to connect to the higher security-level interfaces/network. Provided ofcourse that the NAT or something else doesnt prevent the communication.

Hopefully I havent missed something while going through the configuration. Theres quite alot of it and getting tired

- Jouni

Re: New twist to an old issue

WStoffel1 — Fri, 28 Dec 2012 18:02:17 GMT

That config is a nightmare. No question about it.

Thanks for the input, let me digest it and see what i can accomplish.

I've got a long weekend with some downtime I can try a few different things.

Thanks again.

Will