Technical Tip: TCP Forwarding for RDP via ZTNA Access Behind Site-to-Site VPN

When this topology is implemented:

The FortiClient Endpoint sends RDP connections to the FortiGate via ZTNA. Upon receiving the traffic, the FortiGate checks if ZTNA access is permitted.

If allowed, FortiGate forwards the traffic through the IPsec tunnel. However, by default, the firewall uses the outgoing interface IP address as the source IP, which can cause the tunnel to drop the packet.

Therefore, it is crucial to implement source NAT and ensure the packet has a source IP address within the local subnet of the VPN.

Unlike typical firewall policies, the proxy policy does not include a NAT option. In this scenario, it is necessary to configure an IP pool with an IP address in the VPN's local subnet and apply that IP pool to the proxy policy. For guidance on creating the IP pool, refer to this KB article: Technical Tip: How to configure SNAT with IP pool.

Applying an IP pool to proxy policy:

Create an IP pool using the GUI or CLI. Note that the IP pool must have the default configuration parameter 'set arp-reply enable'.

config firewall ippool

    edit "ZTNA source pool"

        set startip 10.250.11.1

        set endip 10.250.11.10

        set arp-reply enable

    next

end

After configuring the IP pool, assign it to the proxy policy using the CLI:

config firewall proxy-policy

    edit <index>

       set poolname "ZTNA source pool"

    next

end

With this configuration, the FortiGate will use the IP pool range or address for source NAT, enabling connectivity through the VPN interface to the internal virtual server located at a different site.

If arp-reply is disabled, forward traffic will pass, but return traffic will not be recognized as part of the same ZTNA flow, causing the firewall to drop the reply.

Related documents:

Using the IP pool or client IP address in a ZTNA connection to backend servers

New features or enhancements

Technical Tip: ARP reply setting in Virtual IP/IP Pool