Troubleshooting Tip: Authenticated explicit proxy over dialup IPsec connection

In certain scenarios, users need to authenticate to an explicit proxy hosted on a FortiGate firewall, while their connection to the proxy is established over a dial-up IPsec VPN using split-tunnel routing.

A common challenge arises when the user source and group associated with the IPsec VPN do not align with the user source and group required for explicit proxy authentication.

Example scenario:

• IPsec VPN Authentication: Users are authenticated using local user accounts and groups.
• Explicit Proxy Authentication: Users are authenticated via NTLM or Kerberos, with identities sourced from an AD-LDAP server.

Initially, the user can connect to the dial-up VPN using local credentials. However, once automatic authentication to the explicit proxy occurs, the VPN connection remains active temporarily. After some time, the user is unable to access any split-tunnel routes, including the explicit proxy server, leading to stopped traffic forwarding.

Troubleshooting with debug flow on the FortiGate shows that traffic does not match any policy or is being blocked by an implicit deny. Using 'diagnose vpn ike gateway list' confirms that the EAP local user remains authenticated on the VPN; new sessions no longer carry the EAP user credentials, causing connectivity and policy matching issues.

By default, FortiGate has IP-based authentication enabled in the authentication rule. This means that user sessions are tracked by source IP. When explicit proxy authentication occurs, FortiGate treats it as a new authentication for the same IP and replaces the existing VPN session with the proxy-authenticated session. Consequently, the original VPN session loses its user context, which can lead to blocked traffic for split-tunnel routes and other resources that rely on the original VPN authentication.

Several approaches can resolve this issue:

1. Disable authentication on the explicit proxy: This allows traffic to pass without proxy authentication but may introduce security or compliance concerns.
2. Disable explicit proxy authentication for the VPN subnet only: This restricts the workaround to VPN traffic while retaining proxy authentication for other users.
3. Recommended: Disable IP-based authentication in the authentication rule. This ensures that the VPN session and proxy authentication can coexist without overwriting each other.

The following examples illustrate how proxy and firewall authentication behave when IP-based authentication is enabled:

config authentication rule

    edit "TestAuthRule"

        set srcintf "port1"

        set srcaddr "all"

        set ip-based enable

        set active-auth-method "NTLM"

    next

end

Dial-up client successfully connected to the FortiGate:

ProxyLab_600F # diagnose firewall auth list 

192.168.60.10, localuser

        type: fw, id: 0, duration: 20, idled: 2

        server: localuser

        packets: in 2704 out 851, bytes: in 3003932 out 157431

        group_id: 2

        group_name: local_grp

----- 1 listed, 0 filtered ------

Proxy authentication occurs in the background, and the firewall's user session is overwritten with the information from the proxy authentication:

ProxyLab_600F # diagnose firewall auth list 

192.168.60.10, ldapuser

        type: fw, id: 0, duration: 20, idled: 1

        server: ad-ldap

        packets: in 0 out 0, bytes: in 0 out 0

        group_id: 3

        group_name: rem_grp, grp_00037

----- 1 listed, 0 filtered ------

ProxyLab_600F # diagnose wad user list 

ID: 4, VDOM: root, IPv4: 192.168.60.10

  user name   : ldapuser

  worker      : 0

  duration    : 14

  auth_type   : IP

  auth_method : NTLM

  pol_id      : 1

  g_id        : 3

  user_based  : 0

  expire      : no

Behavior with IP-Based Authentication disabled in the 'config authentication rule':

ProxyLab_600F # diagnose firewall auth list 

192.168.60.10, localuser

        type: fw, id: 0, duration: 20, idled: 2

        server: localuser

        packets: in 2704 out 851, bytes: in 3003932 out 157431

        group_id: 2

        group_name: local_grp

----- 1 listed, 0 filtered ------

After proxy authentication completes in the background:

ProxyLab_600F # diagnose firewall auth list 

192.168.60.10, localuser

        type: fw, id: 0, duration: 20, idled: 2

        server: localuser

        packets: in 2704 out 851, bytes: in 3003932 out 157431

        group_id: 2

        group_name: local_grp

----- 1 listed, 0 filtered ------

ProxyLab_600F # diagnose wad user list 

ID: 4, VDOM: root, IPv4: 192.168.60.10

  user name   : ldapuser

  worker      : 0

  duration    : 14

  auth_type   : Session

  auth_method : NTLM

  pol_id      : 1

  g_id        : 3

  user_based  : 0

  expire      : no

As observed, authentication remains separate: VPN traffic correctly matches the intended policies, and the explicit proxy session operates concurrently without interference.

Important note: The reason why this happens is that a single user can be authenticated from multiple IP addresses simultaneously, and each IP address can have only one authenticated user at a time. 

Related articles:

Technical Tip: Explicit proxy with NTLM authentication

Technical Tip: FortiGate explicit proxy authentication with Kerberos