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
object service HTTP
service tcp destination eq www
object service SMTP
service tcp destination eq 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
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 220.127.116.11 41234 <OUTSIDE_INTERFACE_IP> ssh
in <OUTSIDE_INTERFACE_IP> 255.255.255.255 identity
output-interface: NP Identity Ifc
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?
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:
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?
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:
thats should do, I am not a VPN guy, but this shoudl disable webvpn.
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.)
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.
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.
Sure no problem, let me know when you open the case, i'll take it.
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.
Sure no problem, let me know whenever you want to comeback to the original issues.