Technical Tip: Access to Specific FQDN using IPSec VPN Site to Site

[ManoelMartins]

Description	This article describes a specific traffic forwarding through an IPSec VPN Site to Site in which the destination is an FQDN (website) group. The example in the article was defined in the most simple way possible to avoid misunderstanding with others possible configurations. There are two topologies: Flow topology: Visual demonstration of what is expected to have on the flow of the traffic. Physical topology: Showing the IP addresses and interfaces used in this lab.
Scope	FortiGate.
Solution	Flow Diagram:                  Flow Diagram Physical and IP addresses Diagram: Topology Configuration on the FortiGate at the Branch: IPSec VPN Tunnel. As the destination will be a website, it is necessary to be less restrictive on the tunnel and do the management of the destination on the policy, which means defining the remote address configuration with 0.0.0.0/0 on the phase2 as displayed in the image below: Branch-VPN Addresses objects. To have less administrative effort to add more FQDNs on this demand, it is helpful to define a group of them and add more according to the requirements. Website fortinet obj The Static route configuration option is required to be part of an object group that will be used on a Static Route as shown in the next step. Group object. Group obj Note that 'Static route configuration' on the group is enabled from the object as well. Static route. Add a static route using the Named Address and the tunnel as an interface. Add route It displays the default route with the WAN (port2) as a destination, which will send all the traffic to the internet The specific static route created to forward the traffic to the tunnel which has the destination of the websites on the group. From the CLI, it is possible to verify the IP addresses resolved by the DNS defined on the FortiGate. CLI routing table If having DNS resolution issue, the users will access the websites from the Branch ISP instead of the HQ (VPN), like all other traffic as well. Policy for this traffic. For this traffic, it is not necessary to have 2-way policies, but just one as shown in the configuration below. It is not necessary to have NAT in this case. All the process on the Branch is done. Now, let's configure the HQ. Configuration on the Fortigate at the HQ: IPSec VPN Tunnel. To match the selector at the HQ VPN configuration, do the reverse as seen below: Static route. As NAT on the Branch side were not used, just add the subnet from the remote, as demonstrated below: HQ-Static_route The Blackhole is added to avoid a loop, but it is part of another topic. Policy for this traffic. As shown, now it is necessary to enable NAT, because this traffic is forwarding to the internet and there is a requirement. HQ-Policy Everything is done. One simple way to test this traffic is executing a traceroute on the user. The ISP in my lab is 192.168.1.1, then it will display as shown in the image below that one hope is added before the ISP IP address, which means that the traffic to that destination is going through the VPN. If facing some different behaviors from what was exposed here, contact the TAC support to have a proper investigation.