cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1066
Views
0
Helpful
12
Replies

Same Security Traffic, help diagnosing please

WStoffel1
Level 1
Level 1

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!

1 Accepted Solution

Accepted Solutions

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

Might be bug on the version that you are running.

View solution in original post

12 Replies 12

Jennifer Halim
Cisco Employee
Cisco Employee

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

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

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

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).

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

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

Sure..

packet-tracer input CustA tcp 192.168.139.8 10000 192.168.180.26 http

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

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

Might be bug on the version that you are running.

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?

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

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...

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: