cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3223
Views
5
Helpful
21
Replies

Denied Traffic

fasteddye
Level 1
Level 1

We have a put an ASA5505 between us and vendor.  There are only a couple of servers that sit behind this ASA5505 that will talk to vendor.  We have a link setup to the vendor using the outside interface with a 10.10.2.x/30.

The inside network is 10.10.190.x/24.  There is a NAT setup to translate a server on the inside 10.10.190.241 to 10.100.1.140.

static (inside,outside) 10.100.1.140 10.10.190.241 netmask 255.255.255.255.

The server address us 10.10.190.240, so the source is 10.10.190.240 and destination is 10.10.190.241.

We are getting the following in log when the inside server attempts to connect.

Inbound TCP connection denied from 10.10.190.240/3405 to 10.10.190.241/85 flags SYN  on interface inside.

I believe we have the correct routes in place and that it may be an acl issue.

I have not added any acls other than what is standard on an asa5505 out of the box.

I have also tried adding the following thinking they would open up all traffic.

access-list outside_access_in extended permit ip any any
access-list inside_access_in extended permit ip any any

Thanks.

3 Accepted Solutions

Accepted Solutions

Hello

Then the static is backwards, if you would like to use the 10.10.190.241. instead of the 10.100.1.140 the static would be like this

static (outside,inside) 10.10.190.241 10.100.1.140 netmask 255.255.255.255

Take out the one that you have, put this one and try the packet tracer again.

Cheers.

Mike

Mike

View solution in original post

Excellent, thanks for the confirmation.

Here is what you need in terms of translation:

static (outside,inside) 10.10.190.241 10.100.1.140 netmask 255.255.255.255

static (inside,outside) 10.10.190.240 10.10.190.240 netmask 255.255.255.255

The first static NAT above will translate vendor ip address of 10.100.1.140 to 10.10.190.241.

The second static NAT above will keep the inside server ip address of 10.10.190.240 as is.

Then, you would need to enable proxyarp on the inside interface: "no sysopt noproxyarp inside", and "clear xlate" after the above changes.

Then, assuming that you have "inside_access_in" ACL and applied to the inside interface with "access-group inside_access_in in interface inside" command, you should be able to access the vendor server using 10.10.190.241 ip address.

Hope that helps.

View solution in original post

Looks like your inside and outside both have the same security level. In that case, you would need to configure the following:

same-security-traffic permit inter-interface

View solution in original post

21 Replies 21

Maykol Rojas
Cisco Employee
Cisco Employee

Hi!!

My name is Mike, Thank you for posting. I have doubts regarding your configuration and scenario :S.

The server you want to translate is on the inside correct?

The real IP address of the server is 10.10.190.241 and the translated IP address is 10.100.1.140 correct?

What is the destination network, or better, what is the IP scheme of your vendor?

Where is your vendor located (on which interface of the firewall) ?

Can you do the following and send us the output?

Assuming that the vendor is on the outside

packet-tracer input outside tcp 1025  10.10.190.241 80

That information will clear the picture for me, I will be more than glad to continue troubleshooting with you.

Cheers!!!

Mike

Mike

I will be unavailable Monday Oct 18 - through Monday November 1st, 2010.

Server we want translated is on the inside.  Actual IP Address of server is 10.10.190.240.

We have a NAT inside 10.10.190.241 to outside 10.100.1.140.

IP scheme of vendor is 10.100.1.0.  The vendor server is 10.100.1.140.

We connect to vendor on outsdie interface with 10.10.2.192/30.

The application that talks to vendor server uses Port 85.  So here is the scenario, on the inside server 10.10.190.240 we launch a web browser and hit url with 10.10.190.241:85/xxx.

Here are 2 different packet-tracers.

ASA5505# packet-tracer input outside tcp 10.10.1.194 1025 10.10.190.241 80

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   10.10.190.241   255.255.255.255 inside

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

ASA5505# packet-tracer input outside tcp 10.100.1.144 1025 10.10.190.24 80

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   10.10.190.241   255.255.255.255 inside

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

The packet tracer testing that you perform does not match the description that you provided.

What is IP Address of 10.10.1.194, 10.100.1.144 and 10.10.190.24?

You mentioned earlier that inside server ip address is 10.10.190.240, and vendor server ip address is 10.100.1.140 and you would like that to be translated to 10.10.190.241, however your packet tracer testing does not reflect that.

Can you please confirm the following:

1) Traffic is initiated from the inside towards outside?

2) Inside server ip address is 10.10.190.240 (and you do not want any translation for the inside server)?

3) Vendor server ip address is 10.100.1.140, and you would like to translate that ip address to 10.10.190.241?

1. Yes, traffic is initiated from the inside to outside interface

2. Inside server IP is 10.10.190.240 (No translation needed)

3. Vendor server IP is 10.100.1.140 and we would like to translate that IP to 10.10.190.241.

sorry for any confusion, learning as I go here.

ASA5505# packet-tracer input outside tcp 10.10.190.240 1025 10.100.1.14 85

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
static (inside,outside) 10.100.1.140 10.10.190.241 netmask 255.255.255.255
  match ip inside host 10.10.190.241 outside any
    static translation to 10.100.1.140
    translate_hits = 0, untranslate_hits = 3
Additional Information:
NAT divert to egress interface inside
Untranslate 10.100.1.140/0 to 10.10.190.241/0 using netmask 255.255.255.255

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

Hello

Then the static is backwards, if you would like to use the 10.10.190.241. instead of the 10.100.1.140 the static would be like this

static (outside,inside) 10.10.190.241 10.100.1.140 netmask 255.255.255.255

Take out the one that you have, put this one and try the packet tracer again.

Cheers.

Mike

Mike

Excellent, thanks for the confirmation.

Here is what you need in terms of translation:

static (outside,inside) 10.10.190.241 10.100.1.140 netmask 255.255.255.255

static (inside,outside) 10.10.190.240 10.10.190.240 netmask 255.255.255.255

The first static NAT above will translate vendor ip address of 10.100.1.140 to 10.10.190.241.

The second static NAT above will keep the inside server ip address of 10.10.190.240 as is.

Then, you would need to enable proxyarp on the inside interface: "no sysopt noproxyarp inside", and "clear xlate" after the above changes.

Then, assuming that you have "inside_access_in" ACL and applied to the inside interface with "access-group inside_access_in in interface inside" command, you should be able to access the vendor server using 10.10.190.241 ip address.

Hope that helps.

Tried suggestions and still have same log entries.


2 Oct 18 2010 21:36:21  10.10.190.240 1217 10.10.190.241 85 Inbound TCP connection denied from 10.10.190.240/1217 to 10.10.190.241/85 flags SYN  on interface inside

Hello,

Thanks for the cooperation, now would you please do the packet-tracer command with the changes on the configuration?

packet-tracer input inside tcp 10.10.190.240 1025 10.10.190.241 85

Cheers.

Mike

Mike

Tried packet tracer with the following results.

ASA5505# packet-tracer input inside tcp 10.10.190.240 1025 10.10.190.24$

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in 10.10.190.241 255.255.255.255 inside

Phase: 2

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: inside

output-status: up

output-line-status: up

Action: drop

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

Hello,

Thanks for the reply, here is where it gets all confusing......

You launch an application on your inside server which is 10.10.190.240, you try to hit  10.10.190.241 which is an IP on the same subnet as the inside, but you have a nat translation so it can be natted to 10.100.1.140 on the vendor site is that correct?

We need to know how is the traffic flowing, who is going to be the source of the traffic, the destination of the traffic. ports (we know is 85) etc.

Also if you can paste the nat config or the entire config it would be great.

Thanks.

Mike

Mike

You are correct, we are launching a web browser on 10.10.190.240 to access 10.10.190.241 which is on same subnet.

Yes we have a translation so 10.10.190.241 can be natted to 10.100.1.140 on vendor side.

I believe the source traffic would be coming from 10.10.190.240 with destination of 10.10.190.241 natted to 10.100.1.140 on port 85.

I have attached entire config.

Looks like your inside and outside both have the same security level. In that case, you would need to configure the following:

same-security-traffic permit inter-interface

On the configuration I cannot see the statics that we suggested, did you already put them in there?

I can see why the packets are being dropped, but please make sure that the static that you had is no longer in there and the ones that we suggested are on the configuration, also please do not forget the clear xlate.

I will be waiting for your inputs.

Cheers.

Mike

Mike
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: