| Description | This article describes some requirements/considerations when using SSL VPN web mode to access remote servers through an IPsec tunnel. |
| Scope | FortiGate, SSL VPN web mode. |
| Solution |
As a primer, SSL VPN web mode allows remote users to connect and access resources behind the FortiGate using a web browser, rather than needing to install a dedicated application like FortiClient. When using SSL VPN web mode, the FortiGate will act as a proxy on behalf of the user and will use its own interface addresses when initiating connections to these protected resources.
With that in mind, consider the following topology, which includes an IPsec VPN tunnel used by the SSL VPN host FortiGate (FortiGate1) to reach the remote Server:
Topology:
To visit the remote server, check and confirm that the following have been configured:
Before attempting to connect to the server on behalf of the client, the FortiGate will check the routing table to determine the outgoing interface to use to reach a given destination. Once it does, it will use the IP address associated with the interface if it exists.
In the below snippet from the debug flow, the FortiGate is showing that it has used 172.16.1.1 as the Source address to send an ICMP ping to the server at 10.57.1.172:
"148 # id=20085 trace_id=1 func=print_pkt_detail line=5810 msg="vd-root:0 received a packet(proto=1, 172.16.1.1:1280->10.57.1.172:2048) from local. type=8, code=0, id=1280, seq=1.""
For guidance on configuring an IP address on an IPsec tunnel interface, refer to the following article: Technical Tip: Configure IP address on an IPSec tunnel interface.
The debug flow is a useful tool for validating the FortiGate's behavior when it self-originates traffic, as is the packet capture/sniffer tool. Refer to the following documentation for more info on these tools:
Note: IPsec tunnels are unique on the FortiGate as they are one of the few interfaces that can be configured without needing to assign an IP address. However, this is problematic in situations where the FortiGate needs to use the interface to self-originate traffic.
In these situations, the FortiGate will fall back to checking the list of interfaces that do have IP addresses and using the first interface in that list. The FortiGate will most commonly use the IP address of the mgmt interface (if present) or the wan/wan1 interfaces (since the list is based on index numbers and these interfaces are first in the order). To check the list of interfaces, run the following CLI command:
diagnose ip address list
In the following debug flow snippet, the FortiGate did not have an IP address assigned to the IPsec tunnel interface. Instead, it falls back to using the first available IP address in the list, which in this case is the WAN address of 100.64.0.1. Keep in mind that remote VPN devices (such as FortiGate2 in the above diagram) are generally not configured to have routes to these mgmt/wan subnets, and so traffic will often fail to flow successfully.
"148 # id=20085 trace_id=111 func=print_pkt_detail line=5810 msg="vd-root:0 received a packet(proto=1, 100.64.0.1:4352->10.57.1.172:2048) from local. type=8, code=0, id=4352, seq=1.""
Generally, IPsec tunnels on the FortiGate are configured with IPsec Phase 2 Selectors set to 0.0.0.0/0 for both the Local and Remote Address fields. This allows any combination of source/destination addresses to be sent over the VPN tunnel (though it is still restricted based on Firewall Policy configuration).
However, sometimes it is necessary to set specific pairs of subnets in the Phase 2 selector for compatibility with other VPN platforms. If the Phase 2 selectors are not configured to allow this traffic then the FortiGate will drop the traffic before it can be sent over the VPN tunnel. In this example scenario, the Phase 2 selectors must allow 172.16.1.1 (the FortiGate IPsec tunnel address) to reach 10.57.1.172 (the server address).
Despite SSL VPN web mode traffic being technically local-out (FortiGate initiating a connection to the remote resource), it is still a part of SSL VPN and so it requires a Firewall Policy to govern access for users to the remote resource. With that in mind, ensure that Firewall Policies exist that allow traffic to flow from the SSL VPN interface to the outgoing interface (in this case the VPN tunnel interface) along with the appropriate Source Address, Source User/Group, and Destination Address.
With all three requirements satisfied, the SSL VPN web mode client should be able to use the FortiGate to access the remote resource across the IPsec tunnel successfully.
|
