Securely exposing SAP and other ERP systems to remote users while navigating corporate firewalls is a recurring challenge for IT teams. Traditional VPNs based on UDP (IKEv2, OpenVPN-UDP) can be blocked by restrictive perimeter devices or suffer from middlebox interference. SSTP (Secure Socket Tunneling Protocol) offers a firewall-friendly alternative because it encapsulates VPN traffic in TLS over TCP port 443 — the same channel as HTTPS — making it ideal for environments where only web traffic is permitted. This article digs into the technical details, design choices, hardening steps, and operational practices needed to safely deliver SAP & ERP access via SSTP while minimizing performance and compatibility problems.

Why choose SSTP for SAP and ERP access?

SAP landscapes commonly consist of GUI clients (SAP GUI), web-based portals (SAP Fiori), RFC connections, and background app servers. Remote access must support a mix of TCP sessions, long-lived connections, and sometimes large payloads. SSTP brings several advantages:

  • Port 443 traversal: Uses TCP 443 (TLS), which passes through most firewalls and proxies without special rules.
  • TLS security: Leverages SSL/TLS for encryption and server authentication, enabling modern cipher suites and certificate management.
  • Windows native support: Built into Windows clients via the RRAS/SSTP client — reducing client-side configuration and improving end-user UX for many enterprises.
  • Application compatibility: Since SSTP is a full IP tunnel (layer 3), SAP GUI, RFC, HTTP(S), and other protocols run unchanged inside the tunnel.

Key architectural considerations

Designing an SSTP-based gateway for ERP access requires attention to network, authentication, availability, and integration with SAP security controls.

Network topology and routing

SSTP creates a virtual point-to-point interface carrying routed IP traffic. Decide between:

  • Full tunnel: All client traffic is routed through the SSTP gateway. This centralizes inspection, simplifies IP-based access control for SAP servers, and fixes split-DNS issues. But it uses more bandwidth and requires NAT or routing to the public Internet.
  • Split tunnel: Only ERP/SAP subnets are routed via the tunnel; other traffic goes direct. This reduces bandwidth but complicates DNS and firewall policy for SAP resources.

For SAP systems, split tunneling often works if DNS and RFC endpoints are tightly defined. However, to enforce endpoint compliance and monitoring, many enterprises prefer full tunnels.

MTU, MSS clamping and fragmentation

SSTP encapsulates IP packets inside TCP and TLS, increasing packet size. SAP GUI and RFC connections are sensitive to MTU-related issues: large packets can be dropped or cause retransmits leading to poor performance. To mitigate:

  • Lower the tunnel MTU (commonly to 1400–1420 bytes) on server and client interfaces.
  • Enable MSS clamping on the SSTP gateway to cap TCP MSS for passing connections (e.g., set MSS to 1360–1380).
  • Monitor for IP fragmentation and adjust Path MTU Discovery (PMTUD) settings if middleboxes block ICMP “fragmentation needed” messages.

Firewall rules and NAT

On the perimeter firewall, allow inbound TCP 443 to the SSTP gateway IP. If the SSTP endpoint shares a host with HTTPS services, use SNI or port forwarding / reverse proxy solutions, or assign a dedicated public IP for SSTP. Example iptables/nftables rules or security group entries:

  • Allow TCP/443 from client ranges to the SSTP public IP
  • On the SSTP server, allow GRE/ESP only if combined with other VPNs (SSTP itself only needs TCP/443)
  • Apply stateful inspection; permit ESTABLISHED,RELATED

Authentication, certificates, and multi-factor controls

Strong authentication is non-negotiable when providing ERP access. SSTP supports multiple auth modes; best practices include:

  • Server certificates: Use CA-signed TLS certificates for the SSTP service. Avoid self-signed certs except in controlled scenarios. Ensure certificate Common Name (CN) or SAN matches the SSTP host reachable by clients.
  • Client certificates (EAP-TLS): For the highest assurance, use EAP-TLS or client certificate binding. This prevents credential theft and enables device-level authorization.
  • User authentication: Integrate with Active Directory via RADIUS or LDAP. Combine with MFA (TOTP, push-based, or hardware tokens) for interactive logins. On Windows RRAS, combine AD authentication with NPS and MFA adapters.
  • Certificate lifecycle: Automate issuance and revocation. Maintain CRL/OCSP availability for validating client and server certs.

Hardening SSTP deployments

Security hardening reduces attack surface and improves resilience:

  • TLS cipher policy: Disable TLS 1.0/1.1. Prefer TLS 1.2+ with ECDHE key exchange and AEAD ciphers (e.g., ECDHE-RSA-AES256-GCM-SHA384). Disable weak ciphers and legacy RSA key exchange.
  • Minimize services: Run SSTP on a dedicated gateway or hardened host. Remove unnecessary services to reduce lateral attack vectors.
  • Endpoint controls: Require endpoint posture checks (antivirus present, patch level, disk encryption). Leverage Network Access Control (NAC) or posture assessment during authentication.
  • Logging and monitoring: Centralize logs (authentication, connection attempts, session durations) and integrate with SIEM for anomaly detection (multiple failed logins, unusual geolocation, concurrent sessions).
  • Rate limiting: Apply connection rate limits and deny-list brute-force sources at the perimeter.

High availability and scaling

ERP access must be highly available. Consider:

  • Active-active gateway pool: Front SSTP gateway instances with a load balancer that supports TCP 443 passthrough (L4). Because SSTP is stateful over TLS, L7 reverse proxies that terminate TLS can complicate client certificate validation.
  • Stateful syncing: Use solutions that synchronize user sessions or leverage sticky sessions from the load balancer so client reconnects reach the same gateway when necessary.
  • Autoscaling: In cloud environments, autoscale SSTP gateways and register them in DNS or load balancer pools. Keep configuration and certs synchronized via automation tools.
  • Redundancy for authentication services: NPS/RADIUS and AD domain controllers must be redundant and reachable from the SSTP gateways.

Integration with SAP security and networking

Align SSTP VPN policies with SAP security frameworks and network segmentation:

  • SAProuter and RFC: If you use SAProuter or RFC destinations, ensure tunnel routes allow traffic between client IP ranges and SAProuter host. Consider placing SAProuter inside the trusted network and limit access to specific client IPs created by the SSTP VPN.
  • Split DNS: Use split DNS or push DNS via the SSTP session to resolve internal SAP hostnames to private addresses.
  • Whitelisting and dedicated IPs: Some SAP landscape components or external vendors require fixed source IPs. Configure dedicated egress IPs for SSTP gateways or use NAT with reserved public IPs to support vendor whitelisting and licensing expectations.
  • Data confidentiality: Even inside the tunnel, enforce SAP authorization principles — do not rely solely on network controls. Keep transport-level encryption (HTTPS for Fiori) enabled end-to-end.

Troubleshooting common issues

Be prepared for the typical problems that affect SSTP deployments and ERP performance:

TLS handshake failures

Symptoms: client fails to connect showing TLS or certificate errors.

  • Verify server cert validity and chain (CA present on client).
  • Check SNI/virtual hosting requirements if hosting multiple TLS services on the same IP.
  • Inspect firewalls and middleboxes for TLS interception (enterprise proxies) that may break client certificate authentication.

Performance degradation and latency

Symptoms: slow SAP GUI responsiveness, timeouts on RFC calls.

  • Check MTU/MSS settings and reduce tunnel MTU if fragmentation occurs.
  • Monitor TCP retransmits and analyze via packet captures to locate drops or excessive round-trips.
  • Implement QoS for latency-sensitive traffic (SAP GUI control connections), or use WAN acceleration where available.

DNS and resource resolution problems

Symptoms: SAP clients cannot locate internal hosts; Fiori apps return errors.

  • Push internal DNS via the SSTP interface or configure split-DNS so internal names resolve to private addresses.
  • Ensure clients register the tunnel interface’s DNS before attempting to open SAP connections.

Open-source and commercial options

Microsoft RRAS provides native SSTP server capability and is commonly used in Windows-centric environments. Open-source implementations exist (SSTP-Server projects) enabling SSTP on Linux, but they may lag in features or integration. When choosing a vendor or stack, evaluate:

  • Support for EAP methods, client certs, and AD integration
  • Performance under load and ability to scale horizontally
  • Compatibility with enterprise TLS security policies

Operational checklist for deployment

  • Obtain and install CA-signed TLS certificate for SSTP hostname
  • Design network routing (full vs split tunnel) and configure MTU/MSS settings
  • Integrate authentication with AD/RADIUS and enable MFA
  • Harden TLS cipher suites and disable legacy protocols
  • Deploy monitoring for auth/logins and network health
  • Provision dedicated egress IPs if vendor whitelisting is required
  • Document DNS and client configuration steps for SAP GUI and Fiori access

By combining SSTP’s firewall-friendly transport with careful network tuning, strict authentication, endpoint posture checks, and SAP-aligned controls, you can provide robust remote access to SAP and ERP systems without exposing internal services to unnecessary risk. SSTP is not a silver bullet — it should be part of a layered security architecture that includes identity management, endpoint protection, application-level authorization, and continuous monitoring.

For additional guidance on configuring dedicated VPN endpoints, firewall rules, and reserved egress IPs for SAP environments, visit Dedicated-IP-VPN: https://dedicated-ip-vpn.com/