FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
Description This article describes how to let a FortiGate access an internal DNS through a site-to-site IPsec VPN.
Solution In some circumstances, it is necessary to point the FortiGate to an internal DNS server. If that internal DNS server is in a different location connected through an IPsec tunnel originating on the FortiGate, some configuration is required to let the FortiGate send DNS traffic through the tunnel properly. This is necessary as by default, FortiGate uses an outgoint interface IP for traffic, and VPN interfaces do not usually have an IP.
Prerequisites: Site-to-Site VPN fully configured with routing and policies.
There are two options to let a FortiGate access a DNS through site-to-site VPN:
1) Define a source-IP.
This is the option requiring less configuration. The source IP has to be an interface on the FortiGate, and ideally the interface IP behind which is the local network that has access to the VPN in the first place.
As an example:
Local network: 10.0.0.0/24. - FortiGate port1 interface: 10.0.0.17. Remote network: 172.16.0.0/24. Remote DNS server: 172.16.0.250. - Local phase2 selector 10.0.0.0/24 - Remote phase2 selector: 172.16.0.0/24
In CLI, configure the following:
# config sys dns set source-ip 10.0.0.17 set primary 172.16.0.250 end
This allows the FortiGate to send traffic through the VPN utilizing source IP 10.0.0.17. No further configuration for phase2 selectors, policies or routing is required, as FortiGate can rely on the existing setup.
If a different source-IP is selected, then:
- The source IP needs to be added to phase2 selectors. - The source IP needs to be added to policies and routing on the remote side
A downside to this setup is that should the VPN go down, the FortiGate will lose access to the DNS server entirely. No public DNS server can be configured as a secondary server, as the FortiGate is using the configured source-IP to send traffic out its WAN interface. Only a local, internal DNS server works as backup.
2) Configure a transit network for the tunnel.
In cases where FortiGate primarily uses an internal DNS, but have the option to fall back to a public DNS server, source IPs usually cannot be configured, as otherwise the FortiGate is using the (private) source IP to reach out to the public DNS server.
Under such circumstances, a transit network needs to be configured on the VPN directly, similarly to requirements for dynamic routing through a VPN tunnel.
The following needs to be configured:
DNS servers with primary internal and secondary public DNS server, as an example:
# config sys dns set primary 172.16.0.250 set secondary 8.8.8.8 end
A transit network for the tunnel, not in use anywhere else (as an example, 192.168.255.0/30). Then IPs need to be configured on the tunnel interface:
# config sys interface edit test2 set ip 192.168.255.1/32 set remote-ip 192.168.255.2/32 end
Add the configured subnet to the phase2 selectors on both ends. Also add the configured IPs to any required policies on the remote side. With the tunnel IPs configured, that means the FortiGate will use the tunnel-IP (192.168.255.1 in the example) to attempt to contact the internal DNS server. For the public DNS server, use its WAN IP.
