topic Same Security Traffic, help diagnosing please in Network Security

Same Security Traffic, help diagnosing please

WStoffel1 — Tue, 12 Mar 2019 00:23:35 GMT

Why would the drop reason be acl-drop?

Take the following interfaces:

vpnfw# sh run int gig 0/3.139

interface GigabitEthernet0/3.139

vlan 139

nameif test1

security-level 90

ip address 192.168.139.254 255.255.255.0 standby 192.168.139.253

vpnfw# sh run int gig 0/3.180

interface GigabitEthernet0/3.180

vlan 180

nameif test2

security-level 90

ip address 192.168.180.220 255.255.255.0 standby 192.168.180.221

vpnfw# sh run same-security-traffic

same-security-traffic permit inter-interface

same-security-traffic permit intra-interface

vpnfw# ping 192.168.139.8

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.139.8, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/10 ms

vpnfw# ping 192.168.180.26

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.180.26, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

If I go to packet tracer and set the Interface to test1, packet type TCP, source add 192.168.139.8 (a valid working host on that subnet), source port 32000, destination add 192.168.180.26 (again a valid working host for that subnet) dest. port http, i get the following results:

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.180.0 255.255.255.0 test2

Phase: 4

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: FOVER

Subtype: standby-update

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: NAT

Subtype: host-limits

Result: ALLOW

Config:

static (test1,dmz) 192.168.139.0 192.168.139.0 netmask 255.255.255.0

match ip lvbw 192.168.139.0 255.255.255.0 dmz any

static translation to 192.168.139.0

translate_hits = 1564, untranslate_hits = 501

Additional Information:

Phase: 7

Type: NAT

Subtype:

Result: DROP

Config:

nat (test1) 1 192.168.139.0 255.255.255.0

match ip lvbw 192.168.139.0 255.255.255.0 test2 any

dynamic translation to pool 1 (No matching global)

translate_hits = 8, untranslate_hits = 0

Additional Information:

Result:

input-interface: test1

input-status: up

input-line-status: up

output-interface: test2

output-status: up

output-line-status: up

Action: drop

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

Just starting to troubleshoot AND understand this so I'm hoping to learn a few things here

So thanks in advance for any help!

Same Security Traffic, help diagnosing please

Jennifer Halim — Thu, 15 Nov 2012 04:23:58 GMT

Have you "clear xlate" after adding the static NAT statement?

Same Security Traffic, help diagnosing please

WStoffel1 — Thu, 15 Nov 2012 13:50:02 GMT

Yes I have. Now i have a question(s)....My thought was all i needed was the same-seciruty-interface command to allow this. Am i incorrect in my thinking? Is it perhaps because theres existing nats that i would need a nat for this traffic?

Let me start over. The more i read about this the more confused i am I can't put my whole config in but this I believe is all the relavant info below. I have to protect customer info, as subnet 139 is a customer that sits behind my firewall, which i renamed CustA.

CustB is, as you can see from the port forwards, and email product we host. Clearly CustA can't get to the 180 subinterface. And hence email doesn't work for them. How can i go about rectifying this? All of the CustA config has been there a long time (i did not set any of that up). The only thing new is the 180 network and the CustB config.

How can i get this working? And would it benefit me to increase the security level of CustA to say 95 or 100?

The 74.x.x.x addresses below have their associated public DNS entries for mail.domain.com, etc... So essentially right now traffic from 192.168.139.0/24 just gets sent out the default gateway of the ASA, with no hopes of returning.

Thank you so much!

Config:

interface GigabitEthernet0/2

nameif dmz

security-level 50

ip address 192.168.254.254 255.255.255.0 standby 192.168.254.253

interface GigabitEthernet0/3.139

vlan 139

nameif CustA

security-level 90

ip address 192.168.139.254 255.255.255.0 standby 192.168.139.253

interface GigabitEthernet0/3.180

vlan 180

nameif CustB

security-level 90

ip address 192.168.180.220 255.255.255.0 standby 192.168.180.221

same-security-traffic permit inter-interface

same-security-traffic permit intra-interface

nat (CustA) 0 access-list CustA2

nat (CustA) 1 192.168.139.0 255.255.255.0

static (dmz,CustA) 74.11.x.x 192.168.254.11 netmask 255.255.255.255

static (dmz,CustA) 74.11.x.x 192.168.254.19 netmask 255.255.255.255

static (dmz,CustA) 74.11.x.x 192.168.254.4 netmask 255.255.255.255

static (dmz,CustA) 74.11.x.x 192.168.254.32 netmask 255.255.255.255

static (dmz,CustA) 74.11.x.x 192.168.254.14 netmask 255.255.255.255

static (dmz,CustA) 74.11.x.x 192.168.254.52 netmask 255.255.255.255

static (dmz,CustA) 74.11.x.x 192.168.254.50 netmask 255.255.255.255

static (dmz,CustA) 24.7.x.x 192.168.254.2 netmask 255.255.255.255

static (dmz,CustA) 24.7.x.x 192.168.254.13 netmask 255.255.255.255

static (dmz,CustA) 24.7.x.x 192.168.254.35 netmask 255.255.255.255

static (dmz,CustA) 74.112.121.2 192.168.254.1 netmask 255.255.255.255

static (CustA,dmz) 192.168.139.0 192.168.139.0 netmask 255.255.255.0

static (dmz,CustA) 74.11.x.x 192.168.254.62 netmask 255.255.255.255

static (CustA,outside) 74.11.x.x 192.168.139.15 netmask 255.255.255.255

static (CustA,outside) 74.11.x.x 192.168.139.7 netmask 255.255.255.255

static (CustA,outside) 74.11.x.x 192.168.139.6 netmask 255.255.255.255

access-list CustA1 extended permit ip 192.168.139.0 255.255.255.0 172.18.139.0 255.255.255.0

access-list CustA2 extended permit ip 192.168.139.0 255.255.255.0 172.18.139.0 255.255.255.0

nat (CustA) 0 access-list CustA2

nat (CustB) 1 192.168.180.0 255.255.255.0

static (CustB,outside) tcp 74.11.x.x smtp 192.168.180.26 smtp netmask 255.255.255.255

static (CustB,outside) tcp 74.11.x.x 26 192.168.180.26 26 netmask 255.255.255.255

static (CustB,outside) tcp 74.11.x.x 587 192.168.180.26 587 netmask 255.255.255.255

static (CustB,outside) tcp 74.11.x.x www 192.168.180.25 www netmask 255.255.255.255

static (CustB,outside) tcp 74.11.x.x pop3 192.168.180.25 pop3 netmask 255.255.255.255

static (CustB,outside) tcp 74.11.x.x imap4 192.168.180.25 imap4 netmask 255.255.255.255

static (CustB,outside) tcp 74.11.x.x https 192.168.180.25 https netmask 255.255.255.255

static (CustB,outside) tcp 74.11.x.x 993 192.168.180.25 993 netmask 255.255.255.255

static (CustB,outside) tcp 74.11.x.x 995 192.168.180.25 995 netmask 255.255.255.255

static (CustB,outside) 74.11.x.x 192.168.180.72 netmask 255.255.255.255

static (CustB,outside) 74.11.x.x 192.168.180.230 netmask 255.255.255.255

static (dmz,CustB) 74.11.x.x 192.168.254.19 netmask 255.255.255.255

static (dmz,CustB) 74.11.x.x 192.168.254.26 netmask 255.255.255.255

static (CustB,dmz) 192.168.180.0 192.168.180.0 netmask 255.255.255.0

Same Security Traffic, help diagnosing please

WStoffel1 — Thu, 15 Nov 2012 13:51:22 GMT

Oh and customers external to my firewall have no problem accessing email with this setup...but you probably already figured that...thanks again.

Same Security Traffic, help diagnosing please

Jennifer Halim — Thu, 15 Nov 2012 23:22:08 GMT

Don't see a static NAT statement between the 2 interfaces.

YOu would need;

static (CustA,CustB) 192.168.139.0 192.168.139.0 netmask 255.255.255.0

This is assuming that you are accessing the server by its real IP (private IP).

Same Security Traffic, help diagnosing please

WStoffel1 — Fri, 16 Nov 2012 01:11:47 GMT

Now we're getting somewhere! I put the command in, then cleared xlates. Now it's dropped in phase 9

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.180.0 255.255.255.0 CustB

Phase: 4

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

Phase: 5

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: FOVER

Subtype: standby-update

Result: ALLOW

Config:

Additional Information:

Phase: 7

Type: NAT

Subtype:

Result: ALLOW

Config:

static (CustA,CustB) 192.168.139.0 192.168.139.0 netmask 255.255.255.0

match ip CustA 192.168.139.0 255.255.255.0 CustB any

static translation to 192.168.139.0

translate_hits = 3, untranslate_hits = 1

Additional Information:

Static translate 192.168.139.0/0 to 192.168.139.0/0 using netmask 255.255.255.0

Phase: 8

Type: NAT

Subtype: host-limits

Result: ALLOW

Config:

static (CustA,dmz) 192.168.139.0 192.168.139.0 netmask 255.255.255.0

match ip CustA 192.168.139.0 255.255.255.0 dmz any

static translation to 192.168.139.0

translate_hits = 1632, untranslate_hits = 513

Additional Information:

Phase: 9

Type: NAT

Subtype: rpf-check

Result: DROP

Config:

nat (CustB) 1 192.168.180.0 255.255.255.0

match ip CustB 192.168.180.0 255.255.255.0 CustA any

dynamic translation to pool 1 (No matching global)

translate_hits = 1, untranslate_hits = 0

Additional Information:

Result:

input-interface: CustA

input-status: up

input-line-status: up

output-interface: CustB

output-status: up

output-line-status: up

Action: drop

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

What's next

Same Security Traffic, help diagnosing please

Jennifer Halim — Fri, 16 Nov 2012 13:42:48 GMT

Can you pls advise what exactly you run on your packet tracer source and destination IP. Thanks.

Same Security Traffic, help diagnosing please

WStoffel1 — Fri, 16 Nov 2012 17:28:01 GMT

Sure..

packet-tracer input CustA tcp 192.168.139.8 10000 192.168.180.26 http

Same Security Traffic, help diagnosing please

WStoffel1 — Fri, 16 Nov 2012 17:36:20 GMT

And if it helps, i could raise or lower the security level on the CustA interface...

Same Security Traffic, help diagnosing please

Jennifer Halim — Sat, 17 Nov 2012 13:16:41 GMT

would definitely worth a try raising CustA security level to a higher security level.

Might be bug on the version that you are running.

Same Security Traffic, help diagnosing please

WStoffel1 — Sat, 17 Nov 2012 13:42:20 GMT

Thank you!!! That did it for traffic from CustA to CustB. Flawlessly actually.

Not sure if I should start a new thread or continue here, but i have 2 questions now.

1. How do i get traffic from CustB to CustA (or since the traffic would always be initiated from CustA, is this even necessary?)

2. CustB is actually our Hosted Email product, which uses public IP's and DNS entries, is there anyway to get email flowing?

Same Security Traffic, help diagnosing please

Jennifer Halim — Wed, 21 Nov 2012 10:38:42 GMT

1) If traffic only needs to be initiated from CustA to CustB, then the return traffic will be allowed by default.

However, if you need to initiate traffic from Cust B to Cust A, all you need is to configure access-list on Cust B interface to allow the traffic through.

2) It's probably best to use DNS name instead of that actual ip address. However, it will only work if the DNS traffic traverses through the ASA. All you need to do is to add the keyword "dns" on the static NAT statement on the static NAT for the mail server statement.

Eg:

static (CustB,outside) tcp 74.11.x.x smtp 192.168.180.26 smtp netmask 255.255.255.255 dns

Same Security Traffic, help diagnosing please

WStoffel1 — Wed, 21 Nov 2012 12:40:36 GMT

Thank you again! Before I do this, i just want to be sure since i really don't want to cause problems for other clients that are functioning correctly I just love labbing a production network!

You mean of course my existing nat:

static (CustB,outside) tcp 74.11.x.x smtp 192.168.180.26 smtp netmask 255.255.255.255

All i needed to do originally was have the DNS keyword at the end, and that along your earlier help:

static (CustA,CustB) 192.168.139.0 192.168.139.0 netmask 255.255.255.0

...would allow CustB behind my firewall to use a public dns entry for mail.mycompany.com at 74.11.x..x, which is the CustA interface on the same firewall?

Hopefully i worded that correctly...