New Member

Question

Configure policy routes for route-based (interface-based) IPsec VPNs

Forum|Forum|5 years ago
November 24, 2020
9 replies
10304 views

Dear

I have the following scenario. I have a VPN connection between two FG boxes. The FG 80E HQ box is configured as follows:

FG 80E HQ WAN -> 200.168.147.99/29 VPN-HQ -> 10.1.1.1/32 Remote IP / Mask -> 10.1.1.2/255.255.255.252 LAN -> 192.168.254.99/24

FG 50E Branch WAN -> 177.127.147.230/29 VPN-BRANCH -> 10.1.1.2 Remote IP / Mask -> 10.1.1.1 LAN -> 192.168.247.99/24

I configured a route-based policy so that the VPN interface on the FG 80E HQ can obtain subnet access 192.168.247.0/24 and the FG 50E Branch has subnet access 192.168.254.0/24.

However I used this tutorial https://kb.fortinet.com/k....do?externalID=FD38790 to configure access, but it didn't work. Could someone help me?

Toshi_Esumi

SuperUser

To use a policy route, you still need to have a proper route into the tunnel, which is not described in the KB. Do you have a route for the subnet on the opposite end.

Besides, I don't see any particular reason you need to configure a policy route as described in KB. I even want to know why this KB is posted. Because you still need to have a set of policies for both directions and in the policies you can control what sourc/destination combinations are allowed to go/come across. Then further, once you start dealing with multiple VPNs and failovers, you easily get in trouble with the policy route.

emnoc

New Member

I think we should take a step back and identify what is NOT working?

Ken Felix

ede_pfau

SuperUser

As posted, you do not need a policy route at all, hence no local and remote IPs on the tunnel interfaces (but they don't harm either).

Post your routing table and the policy itself and we'll see if anything is misconfigured.

Cleyton_Agenil_da_SiAuthor

New Member

Thanks for the answer

The reason for configuring a policy route as described in KB, would be my problem with the DNS server behind the FG 80E HQ. As I said in the post, I have FG HQ 80E and a FG Branch 50E with VPN connection, the stations that are behind the FG can access the DNS, but the boxes do not ping in CLI mode.

See scenario below:

FG 80E HQ WAN -> 200.168.147.99/29 VPN-HQ -> 10.1.1.1/32 IP / Remote Mask -> 10.1.1.2/255.255.255.252 LAN -> 192.168.254.99 / 24 DNS Windows -> 192.168.254.100 FG 50E Branch WAN -> 177.127.147.230/29 VPN-BRANCH -> 10.1.1.2 IP / Remote Mask -> 10.1.1.1 LAN 192.168.247.99/24 DNS Windows HQ -> 192.168.254.100

When I specify DNS windows in the FG Branch option, as shown in the image attached in this post, an error message appears. DNS server behind FG HQ 192.168.254.100 Unreachable This problem occurs when pinging the DNS server using the CLI command in the FG 50E box. As the image attached in this post

DNS-CLI.jpg

emnoc

New Member

So what I would do is set a interface address on both the vpn-interface and ensure that hq and branch FGT negotiate a phase2 for that subnet and your ping will work along as the remote-firewall has a policy allowing that ping to the machine behind on the law.

You will need routes install to allow the HQ to Branch and Branch to HQ for whatever tunnel interface addresses that you assign. Use a combination of "diag sniffer packet <phase1-interface-name> "host x.x.x.x and proto 1" to witness the ping and on the remote firewall "diag debug flow filter" with the correct filters to witness the ping and the policy action that is taken.

This is trivial to setup and pbr is not required.

Ken Felix

ede_pfau

SuperUser

May I translate emnoc's advice "and pbr is not required" = pbr/policy based route.

Please note that pinging from the FGT's CLI can sometimes fail because the originating address is not the one you expect. Ping from a host on the LAN to see if your routing is correct.

You do neither need policy routes, nor tunnel and remote IP addresses. Before further testing, delete at least the PBR.

And again, if you would post ALL relevant information we could have solved your problem long ago.

Sign up

Login with SSO

Login to the community

Login with SSO