Secure Remote Access: Configure SSTP VPN on Cisco ASA Firewalls — A Step-by-Step Guide

Why SSTP vs. ASA: compatibility and design considerations

Secure Socket Tunneling Protocol (SSTP) is a Microsoft-designed VPN transport that encapsulates PPP over HTTPS (TCP/443). It is popular because it traverses strict firewalls and proxies that block UDP-based VPNs. However, it’s important to understand that Cisco ASA does not natively implement SSTP as a server protocol. The ASA’s native secure remote access offering is SSL VPN (WebVPN) and the AnyConnect SSL/IPsec client, which use TLS-based channels and provide equivalent traversability and strong cryptography.

Because of this, there are two practical deployment patterns if you need SSTP specifically:

• Terminate SSTP on a Windows RRAS or another SSTP-capable server and place the ASA in front as a firewall/NAT device (ASA passes port 443 to the SSTP server).
• Use ASA’s SSL VPN (AnyConnect) as a direct replacement for SSTP. AnyConnect provides robust TLS-based remote access over TCP/443 (or DTLS/UDP for performance) and is fully supported on ASA.

The rest of this guide focuses on a secure, production-ready remote access configuration using Cisco ASA’s SSL VPN (AnyConnect) as the recommended alternative to SSTP, and also shows how to integrate ASA with an SSTP backend if you must support Microsoft clients natively.

Preconditions and design checklist

Before making configuration changes, validate these items:

• ASA model and software: Ensure your ASA hardware and ASA OS version support AnyConnect image, WebVPN and sufficient throughput. Example: ASA 5506-X/5508-X with ASA 9.8+ for full TLS1.2 support.
• SSL certificate: A public CA-signed certificate for the vpn FQDN (e.g., vpn.example.com) to avoid client trust prompts. Subject Alternative Names (SAN) permitted.
• Licensing: AnyConnect licenses and SSL VPN-capable ASA license (AIP SSM or appropriate feature set).
• Network plan: Internal address pool or client-assigned subnets, DNS/WINS forwarding, split-tunnel vs. full-tunnel decision, and NAT rules to allow internal resource access.
• AAA: Authentication backend (Local, RADIUS, or LDAP). For enterprise use, RADIUS with NPS or TACACS+ for additional accounting is recommended.
• Firewall rules: Permit TCP/443 and UDP/443 (DTLS) if you want to use DTLS for improved performance with AnyConnect.

Step 1 — Prepare the SSL certificate and ASA trustpoint

AnyConnect and WebVPN require an SSL certificate bound to the ASA. Use a certificate whose Subject CN matches the external FQDN that clients will connect to (e.g., vpn.example.com).

Example workflow:

• Generate a CSR on the ASA, submit to CA, and import the signed certificate and CA chain.

Sample commands (ASA CLI):

Generate a key and CSR:
crypto key generate rsa label vpn-key modulus 2048
crypto ca trustpoint VPN-TP
enrollment terminal
fqdn vpn.example.com
subject-name CN=vpn.example.com,OU=IT,O=Example Inc,C=US
keypair vpn-key

Paste the CSR to the CA, then import the certificate and CA chain:

Import cert:
crypto ca authenticate VPN-TP
(copy/paste CA chain)
crypto ca import VPN-TP certificate
(copy/paste issued certificate)

Bind the trustpoint to the interface that terminates the SSL session (usually the outside interface):

ssl trust-point VPN-TP outside

Step 2 — Configure the AnyConnect image and WebVPN

Upload AnyConnect client packages (Windows, macOS, Linux, and perhaps webdeploy) to the ASA flash and create a WebVPN configuration.

Key CLI steps:

• Upload packages (using ASDM or SFTP/FTP) into disk0:/.
• Enable WebVPN and point to the client package location.

Commands:

webvpn
enable outside
anyconnect image disk0:/anyconnect-win-4.x.x.pkg 1
anyconnect image disk0:/anyconnect-macos-4.x.x.pkg 2
anyconnect enable outside

Step 3 — Define tunnel group, group-policy, and address pool

Decide whether to use clientless, full tunnel, or split tunnel. For secure remote access, many organizations use split-tunnel with strict split-exclude lists or full-tunnel when traffic must always traverse corporate security stacks.

Example configuration using a DHCP-like pool (for IPv4):

Define an address pool:

ip local pool VPN_POOL 10.10.100.10-10.10.100.100 mask 255.255.255.0

Create a group-policy that controls split tunneling, DNS, and client features:

group-policy VPN-GROUP internal
group-policy VPN-GROUP attributes
dns-server value 10.10.10.10
vpn-tunnel-protocol ssl-client
split-tunnel-policy tunnelspecified
split-tunnel-network-list value SPLIT-TUNNEL-LIST

Define an access-list for split-tunnel networks (networks that go through the tunnel):

access-list SPLIT-TUNNEL-LIST standard permit 10.10.0.0 255.255.0.0

Create the tunnel-group which ties AAA, address pool, and group policy:

tunnel-group VPN-EXT type remote-access
tunnel-group VPN-EXT general-attributes
address-pool VPN_POOL
default-group-policy VPN-GROUP
tunnel-group VPN-EXT webvpn-attributes
group-alias VPN-EXT enable

Authentication backend (RADIUS example)

Configure RADIUS (NPS) for authentication and optional accounting:

radius-server host 10.20.30.40 auth-port 1812 acct-port 1813 key StrongSharedSecret

Then bind to AAA-server group if using CLI-based policy:

aaa-server RADIUS-SERVERS protocol radius
aaa-server RADIUS-SERVERS (inside) host 10.20.30.40
key StrongSharedSecret

And point the ASA WebVPN/AnyConnect to use that AAA server in the tunnel-group if needed.

Step 4 — NAT, ACLs, and inside resource access

Ensure the ASA’s NAT rules do not interfere with VPN client traffic. For example, if internal resources are behind NAT, configure identity NAT or NAT exemption so VPN clients can reach them.

Example NAT exemption (ASA versions 8.3+):

object network VPN-CLIENTS
subnet 10.10.100.0 255.255.255.0
object network INTERNAL-SERVER
host 10.10.10.5
nat (inside,outside) source static VPN-CLIENTS VPN-CLIENTS destination static INTERNAL-SERVER INTERNAL-SERVER no-proxy-arp route-lookup

Create ACLs on inside resources as necessary. For high security, implement least-privilege ACLs and log denials.

Step 5 — Firewall policy and ASA access rules for management ports

Permit inbound TCP/443 (and optionally UDP/443 for DTLS) to the ASA outside interface. If you terminate SSTP on a backend server, permit TCP/443 to the internal SSTP host and configure static port forwarding (static PAT) on ASA.

Example ACL to allow client-initiated TCP/443 (applied to outside):

access-list OUTSIDE-IN permit tcp any interface outside eq 443

Apply to the outside interface:

access-group OUTSIDE-IN in interface outside

If terminating SSTP behind the ASA, use static PAT:

object network SSTP-SERVER
host 192.168.1.50
nat (inside,outside) static interface service tcp 443 443

Step 6 — Testing and client deployment

Test connectivity progressively:

• Verify ASA is listening on TCP/443: show webvpn and show ssl.
• From external network, attempt to reach https://vpn.example.com and confirm the ASA presents the certificate.
• Install AnyConnect client and attempt VPN connection. Monitor ASA logs: show vpn-sessiondb and show logging.
• Verify assigned IP, internal resource access, DNS resolution, and split-tunnel behavior.

For SSTP termination behind ASA, test that port 443 is forwarded to the SSTP server and that clients can authenticate and obtain routes. Use packet captures on the ASA (capture) to troubleshoot.

Troubleshooting checklist

• Certificate errors: ensure the FQDN in the certificate matches the URL clients use, and full chain is installed on ASA.
• Authentication failures: verify RADIUS shared secret, user credentials, and user group mappings; check NPS logs.
• Address assignment issues: check local pool exhaustion or conflicts; confirm split-tunnel ACLs.
• Performance/DTLS: if you see high latency, enable DTLS and allow UDP/443 for AnyConnect to use DTLS where available.
• SSTP-specific issues (if terminating on Windows): capture traffic and confirm TCP 443 is reaching the RRAS role, certificate on RRAS is valid, and TCP socket is not blocked by ASA inspection rules.

Security best practices

• Use a strong, publicly-trusted certificate and disable weak TLS ciphers on the ASA (enable TLS 1.2+ and revoke TLS 1.0/1.1).
• Enforce multi-factor authentication (MFA) — integrate RADIUS with an MFA provider or use Duo/Okta with RADIUS/EAP for second factor.
• Apply least privilege on group-policy ACLs and restrict internal resources to only required subnets.
• Enable logging and integrate with SIEM for real-time monitoring of remote access events.
• Patch and update ASA images and AnyConnect clients regularly to address vulnerabilities.

When you must support native SSTP clients

If you have a requirement to support Microsoft SSTP clients specifically (for example, legacy Windows clients that expect an SSTP server), the pragmatic architecture is:

• Deploy a Windows Server with RRAS (or another SSTP-capable endpoint) inside your DMZ.
• Use ASA static PAT to forward TCP/443 from the ASA outside interface to the SSTP server on the inside network.
• Terminate SSL on the SSTP server using a certificate matching the public FQDN and ensure the ASA does not perform SSL inspection on that flow.
• Use RADIUS/NPS for authentication if you want central AAA and MFA integration.

This approach preserves native SSTP support while still leveraging the ASA for perimeter firewalling, NAT, and inspection.

Conclusion and further resources

While Cisco ASA does not natively provide a Microsoft SSTP server, it fully supports TLS-based SSL VPNs via AnyConnect and WebVPN that meet or exceed SSTP’s traversal and security goals. For environments that require SSTP specifically, terminate SSTP on an SSTP-capable server behind the ASA and forward TCP/443. For most modern deployments, AnyConnect on ASA is the recommended path because it integrates with ASA policy controls, AAA, and offers superior client manageability.

For detailed command references and ASA platform-specific nuances, consult Cisco’s configuration guides and your ASA platform release notes. If you’re publishing configuration snippets or automating deployments, verify commands against your ASA OS version to avoid syntax differences.

Published by Dedicated-IP-VPN — more deployment guides and configuration examples available at https://dedicated-ip-vpn.com/