I've got a really basic WebVPN configuration going and for some reason I cannot even get the portal to show. I keep receiving the following error in my syslog:
%ASA-6-710003: TCP access denied by ACL from x.x.x.188/2856 to outside:y.y.y.14/443
Here's my relevant WebVPN config:
ASA Version 8.0(4)
ssl trust-point my.webvpn.trustpoint outside
csd image disk0:/csd_3.4.1108.pkg
svc image disk0:/anyconnect-win-2.3.0254-k9.pkg 1
group-policy global_policy internal
group-policy global_policy attributes
dns-server value 192.168.10.18 192.168.10.21
vpn-tunnel-protocol svc webvpn
default-domain value fubar.lcl
address-pools value global_vpn_pool
svc dtls enable
svc keep-installer installed
svc keepalive 20
svc rekey method ssl
svc dpd-interval client 20
svc dpd-interval gateway 30
svc ask enable
username blah password asd3aeiWEDdC$#3 encrypted privilege 15
tunnel-group global_tunnel type remote-access
tunnel-group global_tunnel general-attributes
authentication-server-group RADIUS LOCAL
tunnel-group global_tunnel webvpn-attributes
group-alias Global_Employees enable
group-url https://webvpn.fubar.com/global_employees enable
I thought that with the sysopt connection permit-vpn command all ACL's would be bypassed?? I can't even find which ACL it is referring to. Thanks ahead of time.
I could only assume that the ACL being referred to is the 'Outside' ACL permiting / denying traffic from outside, have you tried adding a permit statement to this ACL to test?
Thank you for your reply. Yes, I have attempted to add an ACE in my outside_access_in ACL, but the hit counter never increments. The sysopt connection permit-vpn default should allow it to bypass this??
At any rate here is my outside_access_in ACL (the third ACE is what I added for this):
access-list outside_access_in extended permit object-group SMTP_PORTS object-group MXLOGIC_ADDYS host x.x.x.114
access-list outside_access_in extended permit tcp object-group MXLOGIC_ADDYS host x.x.x.117 eq ldaps
access-list outside_access_in extended permit tcp any host x.x.x.114 eq https
access-list outside_access_in extended permit tcp any host x.x.x.114 eq 3389
access-list outside_access_in extended permit tcp any host x.x.x.115 eq https
access-list outside_access_in extended permit tcp any host x.x.x.116 eq https
access-list outside_access_in extended permit tcp any host x.x.x.117 eq 3389
access-list outside_access_in extended permit tcp any host x.x.x.118 eq www
access-list outside_access_in extended permit tcp any host x.x.x.118 eq https
access-list outside_access_in extended permit icmp any any echo-reply
access-list outside_access_in extended permit icmp any any unreachable
access-list outside_access_in extended permit icmp any any time-exceeded
access-list outside_access_in extended permit icmp any any source-quench
access-list outside_access_in extended deny ip any any log
Edit: The error message specified in the original post is the same one you'll see in your syslog for attempts to access such things as ssh or asdm from invalid hosts. It seems like it is trying to access the asdm interface even though I've got this running on TCP/4343.
Edit #2: I have successfully created a WebVPN presence on a spare 5505 unit in a lab environment; it took all of about 2 minutes to get it up and running. The setup is virtually the same with the exception of the IP addresses. I may have to open a case with TAC on this one.
Sorry Steve, I didn't see this response. I added a few edits to my previous post. As for the show run sysopt, nothing is shown in the output.
ASA# show run sysopt
I can enter the command sysopt connection permit-vpn 80 million times and it will still not show up anywhere.
Sorry, forgot to add, are you doing any kind of port forwarding that may affect this?
No I am not. WebVPN is enabled on the outside interface and the outside IP is PATed for inbound SMTP access and inbound RDP access (oooh I can't wait to get rid of this one lol) at this time. HTTPS traffic is not being forwarded on this particular IP.
Ok, so I rebooted the device after hours and once it came back up I was able to connect. Wierd. Thanks for your assistance anyway.