FortiGate IPsec Dial-up VPN with Microsoft Entra ID (SAML)

Overview

This document covers the configuration required to implement an IPsec Dial-up VPN using Microsoft Entra ID (Azure AD) SAML authentication on FortiGate.

This was developed on FortiOS 7.6.x and includes notes regarding:

• SAML certificates
• Shared IKE TCP/SAML ports
• Interface configuration
• Phase 1/2 baseline
• Authentication behaviour
• Lessons learned during implementation

Certificate Configuration

The same certificate should be referenced by both the authentication daemon and the SAML server configuration.

VDOM Configuration

Authentication certificate

config user setting
    set auth-cert "ravpn-cert"
end

SAML certificate

config user saml
    edit "SAML-AZURE-V2"
        set cert "ravpn-cert"
    next
end

Both references should point to the same public certificate.

TCP Port Configuration

Two different ports exist.

IKE over TCP Port (VDOM)

config system settings
    set ike-tcp-port 443
end

This is the port used by IPsec over TCP.

SAML Authentication Port (Global)

config system global
    set auth-ike-saml-port 1001
end

Historically this port was used for SAML authentication.

Shared Port Behaviour

FortiOS 7.6.x supports sharing the IKE over TCP port for both:

• IKE over TCP
• SAML authentication

Even if:

set auth-ike-saml-port 1001

is configured globally, the FortiClient can successfully use only the IKE TCP port.

Example:

FortiGate

IKE TCP Port      : 443
Auth IKE SAML Port: 1001

FortiClient

VPN Port : 443
SSO Port : 443

This works correctly.

During testing it was confirmed that the client does not need to use port 1001 when the shared-port feature is used.

Interface Configuration

The interface receiving the incoming IPsec connection must reference the SAML server.

Example:

config system interface
    edit "WAN_INTERFACE"
        set ike-saml-server "SAML-AZURE-V2"
    next
end

If a loopback interface is used as the VPN endpoint, configure the loopback instead.

Phase 1 Baseline

config vpn ipsec phase1-interface
    edit "IPSEC-RA-PROD"
 
        set type dynamic
        set interface "$(IP_TRANSIT_INT)"
 
        set ike-version 2
        set peertype any
 
        set authmethod psk
        set psksecret <PSK>
 
        set net-device disable
 
        set mode-cfg enable
 
        set ipv4-start-ip $(P2S_VPN_RANGE_START)
        set ipv4-end-ip $(P2S_VPN_RANGE_END)
 
        set proposal aes256-sha256
 
        set dpd on-idle
 
        set nattraversal enable
 
        set transport auto
 
        set eap enable
        set eap-identity send-request
 
        set transport tcp
 
    next
end

Phase 2 Baseline

config vpn ipsec phase2-interface
    edit "IPSEC-RA-PROD-P2"
 
        set phase1name "IPSEC-RA-PROD"
 
        set proposal aes256-sha256
 
        set pfs disable
 
        set replay enable
 
    next
end

Authentication Groups

Two approaches are possible.

Option 1

Use an authentication group directly under Phase 1.

Option 2 (Recommended)

Do not configure an authentication group under Phase 1.

Instead, perform user/group enforcement in the firewall policies.

Example:

Incoming Interface:
    IPSEC-RA-PROD
 
Source Users:
    Azure / LDAP Groups

This keeps the design consistent with existing SSL VPN deployments and centralises access control within the firewall policies.

Certificate Notes

The public certificate should be imported using:

• Server certificate
• Private key
• Intermediate certificate

The Root CA should not be bundled with the server certificate.

The certificate chain should be:

Server Certificate
        |
        v
GoDaddy Intermediate CA
        |
        v
GoDaddy Root CA

OpenSSL Commands

Build combined certificate

cat server.pem intermediate.pem > combined.pem

Build PKCS12

openssl pkcs12 -export \
    -out vpn.pfx \
    -inkey private.key \
    -in combined.pem \
    -name "ravpn-cert"

Test certificate

openssl s_server \
    -accept 10443 \
    -cert server.pem \
    -key private.key \
    -cert_chain intermediate.pem \
    -www

If Windows trusts this server, the certificate bundle is correct.

Lessons Learned

• auth-cert and the SAML server should reference the same certificate.
• The interface terminating the VPN must reference the SAML server using set ike-saml-server.
• FortiOS 7.6.x supports using the same TCP port for both IKE over TCP and SAML authentication.
• Even when auth-ike-saml-port is configured as 1001, FortiClient can successfully use only the IKE TCP port (for example 443) for both VPN and SSO.
• Authentication can be performed using Azure AD SAML while firewall policies continue enforcing access based on user groups, keeping the design aligned with traditional SSL VPN deployments.