10-18-2010 03:29 PM - edited 03-11-2019 11:56 AM
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.
Solved! Go to Solution.
10-18-2010 06:30 PM
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
10-18-2010 06:31 PM
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.
10-18-2010 06:57 PM
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
10-18-2010 04:26 PM
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
That information will clear the picture for me, I will be more than glad to continue troubleshooting with you.
Cheers!!!
Mike
10-18-2010 04:27 PM
I will be unavailable Monday Oct 18 - through Monday November 1st, 2010.
10-18-2010 05:39 PM
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
10-18-2010 06:12 PM
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?
10-18-2010 06:25 PM
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
10-18-2010 06:30 PM
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
10-18-2010 06:31 PM
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.
10-18-2010 06:40 PM
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
10-18-2010 06:44 PM
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
10-18-2010 06:49 PM
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
10-18-2010 06:21 PM
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
10-18-2010 06:42 PM
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.
10-18-2010 06:57 PM
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
10-18-2010 07:00 PM
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
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: