05-14-2012 01:21 AM - edited 03-11-2019 04:06 PM
Hi all,
We have a problem with a customer's ASA5510, running 8.4(2).
We are trying to configure the device to publish an internal server to the outside, on ports HTTP,HTTPS and SMTP. Also, I've been trying to publish an internal router's SSH service to the outside (for testing purposes). The issue seems to be two phased, so I'll try to split them...
1) No matter what ACL we write, we always end up getting to the implicit deny rule, making the connection drop.
We have configured nat on the device, to publish services on the outside. We have tried both manual and auto-nat strategy, and it all seems to get stuck at the ACL (regarding the system log). In the attached current configuration, I've done configuration for the internal server (SERVER-TMG, 192.168.101.13) to publish it's HTTP and SMTP services on the outside interface, via manual nat.
object network SERVER-TMG
host 192.168.101.13
description SERVER-TMG
!
object service HTTP
service tcp destination eq www
description HTTP
!
object service SMTP
service tcp destination eq smtp
description SMTP
!
nat (outside,inside_1) source static any any destination static interface SERVER-TMG service SMTP SMTP unidirectional
nat (outside,inside_1) source static any any destination static interface SERVER-TMG service HTTP HTTP unidirectional
Also, for testing, I've done auto-nat configuration for the internal router's SSH service, as below...
object network ROUTER-R1
host 192.168.220.253
!
object network ROUTER-R1
nat (inside_1,outside) static interface service tcp ssh ssh
!
The outside interface ACL is also configured:
access-list outside_access_in extended permit tcp any object ROUTER-R1 eq ssh
access-list outside_access_in extended permit ip any any
access-list outside_access_in extended permit ip object RemoteVpnNet any log disable
access-list outside_access_in extended permit object HTTPS any any
access-list outside_access_in extended permit object HTTP any any
access-list outside_access_in extended permit object SMTP any any
access-list outside_access_in extended permit tcp any any eq ftp
access-list outside_access_in extended permit tcp any any eq ftp-data
access-group outside_access_in in interface outside
(I've even put in permit ip any any in there, just to make sure I'm not missing anything)
But even with this configuration, a packet-trace shows packets are dropped at the ACL (the implicit deny rule)...
ciscoasa# packet-tracer input outside tcp 5.5.5.5 41234 <OUTSIDE_INTERFACE_IP> ssh
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in <OUTSIDE_INTERFACE_IP> 255.255.255.255 identity
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: NP Identity Ifc
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
Can anyone introduce any sense into this??? Are we missing anything?
2) This ASA had webvpn configured on the outside interface... I've yet disabled it (webvpn -> no enable outside) and even enabled it again on another port, but whatever I do, connections to the outside interface of the ASA redirects to "https://<OUTSIDE_INTERFACE_IP>/+CSCOE+/logon.html" as if webvpn is still running there...
This, also means that I cannot do NAT/PAT for the <outside_interface_ip>:443 to the internal server...
ciscoasa(config)# nat (outside,inside_1) source static any any destination static interface SERVER-TMG service HTTPS HTTPS unidirectional
ERROR: NAT unable to reserve ports.
Any ideas on this?
05-14-2012 01:43 AM
Hi,
can you please try this:
objects service tcp_22
service tcp destination eq 22
nat (outside,inside_1) 1 source static any any destination static interface SERVER-TMG service SMTP SMTP
nat (outside,inside_1) 2 source static any any destination static interface SERVER-TMG service HTTP HTTP
nat (outside,inside_1) 3 source static any any destination static interface ROUTER-R1 service tcp_ssh tcp_ssh
nat (any,any) source static RemoteVpnNet RemoteVpnNet ----> This nat statement might cause issues, always keep it as specific as possible.
Use the nat rules on line 1,2 and 3. Moreover, go for captures as well, they would tell you that exact story:
https://supportforums.cisco.com/docs/DOC-17814
Thanks,
Varun Rao
Security Team,
Cisco TAC
05-14-2012 01:58 AM
Hi Varun,
Thanks for the prompt reply...
But, the SSH service is for testing purposes, that's why I've stick to auto-nat for it (to see if manual nat has problems and auto-nat is the solution).
As you'd guess, nothing has changed.
Regarding the RemoteVpnNet line, as far as I can guess that's the NAT exemption rule, telling the device not to NAT packets from remote vpn clients... Do you really think that might be the cause?
And, any idea on why I cannot disable webvpn / free https port on asa?
05-14-2012 02:20 AM
Hi,
Nat order of search is from top to bottom, which means manual nat would be searched first and then auto nat, and if the traffic hits the first matching statment, it would take that.
To disable the webvpn, I guess you would just need to do:
no webvpn
thats should do, I am not a VPN guy, but this shoudl disable webvpn.
Thanks,
Varun Rao
Security Team,
Cisco TAC
05-14-2012 03:14 AM
You're right, but the thing is, I've moved all the manual NAT lines below auto-nat with ASDM, and that also didn't change a thing...
About the webvpn, those were what I also knew, but interestingly even right after giving "no webvpn" command, running-configuration shows "webvpn"...
Might this be a bug, would you advise us to open a TAC case about it? (I've not encountered anything like this in the Bug Tracker yet though.)
05-14-2012 03:26 AM
Hi,
Yes, I guess opening a TAC case would b the right option, since we would need to have a look at the setu to identify the cause for it. Bug doesn't seem probable at the moment although need to dig into it to identify. If you are in the European timezone, I can pick the case for the nat issue.
Thanks,
Varun Rao
Security Team,
Cisco TAC
05-14-2012 03:28 AM
We are in GMT+3 (Turkey) so that's probable
Let me consult with my manager and proceed with the case... Hope you'll be the engineer assigned
Thanks for everything till now.
05-14-2012 03:30 AM
Sure no problem, let me know when you open the case, i'll take it.
Thanks,
Varun Rao
Security Team,
Cisco TAC
06-01-2012 03:07 PM
Hi Varun,
Sorry for the time without updates... During this time, we learned that the customer has arranged a subnet of IP addresses to be routed over to their ASA. Publishing the server(s) and services over these external IPs have been succesfull without effort.
So, the idea of having a TAC case is slightly dismissed for the time being, as we're pretty busy, trying to get things running.
I believe, after getting everything else in order, we can go back to these two issues.
Thanks for your efforts though.
06-01-2012 03:18 PM
Sure no problem, let me know whenever you want to comeback to the original issues.
Thanks,
Varun Rao
Security Team,
Cisco TAC
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide