Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Cleyton_Agenil_da_Si
New Contributor

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

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?

9 REPLIES 9
Toshi_Esumi
SuperUser
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
Esteemed Contributor III

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

 

Ken Felix

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
ede_pfau

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.

Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
Cleyton_Agenil_da_Si
New Contributor

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

emnoc
Esteemed Contributor III

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

 

 

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
ede_pfau

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.

Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
Cleyton_Agenil_da_Si

Dear ede_pfau and emnoc Thank you for your help.

My intention to create Policy Based on route - pbr, would be to solve problem with access to the windows DNS server through the "DNS Settings" in the FG console, I don't know if this is the best option to solve the problem, since the address pattern VPN interface 0.0.0.0 IP / Remote 0.0.0.0/0.0.0.0

 

FG 50E Branch

Branch # ping 10.1.1.1 -> VPN Interface IP / Remote HQ PING 10.1.1.1 (10.1.1.1): 56 data bytes 64 bytes from 10.1.1.1: icmp_seq = 0 ttl = 255 time = 27.0 ms 64 bytes from 10.1.1.1: icmp_seq = 1 ttl = 255 time = 25.8 ms 64 bytes from 10.1.1.1: icmp_seq = 2 ttl = 255 time = 26.1 ms 64 bytes from 10.1.1.1: icmp_seq = 3 ttl = 255 time = 26.1 ms 64 bytes from 10.1.1.1: icmp_seq = 4 ttl = 255 time = 26.1 ms

--- 10.1.1.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min / avg / max = 25.8 / 26.2 / 27.0 ms

Branch # ping 192.168.247.99 -> LAN Branch Interface PING 192.168.247.99 (192.168.247.99): 56 data bytes 64 bytes from 192.168.247.99: icmp_seq = 0 ttl = 255 time = 0.1 ms 64 bytes from 192.168.247.99: icmp_seq = 1 ttl = 255 time = 0.1 ms 64 bytes from 192.168.247.99: icmp_seq = 2 ttl = 255 time = 0.1 ms 64 bytes from 192.168.247.99: icmp_seq = 3 ttl = 255 time = 0.1 ms 64 bytes from 192.168.247.99: icmp_seq = 4 ttl = 255 time = 0.1 ms

--- 192.168.247.99 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min / avg / max = 0.1 / 0.1 / 0.1 ms

Branch # ping 192.168.254.99 -> HQ LAN interface PING 192.168.254.99 (192.168.254.99): 56 data bytes

--- 192.168.254.99 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss

 

IPSEC PHASE1-INTERFACE VPN

 

BRANCH (phase1-interface) # show config vpn ipsec phase1-interface edit "VPN-BRANCH" set interface "wan1" set local-gw XXX.XXX.XXX.XXX set peertype any set net-device disable set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1 set remote-gw XXX.XXX.XXX.XXX set psksecret ENC TQjyRi4nEWBfFVy5 / NSwjDh4BJxJ9mKQbaMjv9IX2xlaIgspZaxYvhu8xhgavi4WA2njHxsQFfu3ukSJkAMoT / Rvpvur67F4H9JZY2Q3QQQQQQQQQQQQQQQQQQQQQQQQQQQQQVMZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ) next end

IPSEC PHASE2-INTERFACE VPN Branch (phase2-interface) # show config vpn ipsec phase2-interface edit "VPN-BRANCH" set phase1name "VPN-BRANCH-HQ" set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm aes256gcm chacha20poly1305 set auto-negotiate enable set src-addr-type name set dst-addr-type name set src-name "192.168.247.0/24" set dst-name "192.168.254.0/24" next edit "VPN-BRANCH" set phase1name "VPN-BRANCH-HQ-DNS" set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm aes256gcm chacha20poly1305 set auto-negotiate enable set src-addr-type name set dst-addr-type name set src-name "10.1.1.2/32" set dst-name "10.1.1.1/32" next end

Route Static

BRANCH (4) # get seq-num: 4 status: enable dst: 0.0.0.0 0.0.0.0 distance: 1 weight: 0 priority: 0 device: VPN-BRANCH comment: blackhole: disable dynamic-gateway: disable dstaddr: 10.1.1.1/32 link-monitor-example: disable bfd: disable ------------------------------------------------- / / ------------------------------------------------- - FG 80E HQ

HQ # ping 10.1.1.2 IP VPN / Remote Branch interface PING 10.1.1.2 (10.1.1.2): 56 data bytes 64 bytes from 10.1.1.2: icmp_seq = 0 ttl = 255 time = 26.5 ms 64 bytes from 10.1.1.2: icmp_seq = 1 ttl = 255 time = 26.3 ms 64 bytes from 10.1.1.2: icmp_seq = 2 ttl = 255 time = 26.3 ms 64 bytes from 10.1.1.2: icmp_seq = 3 ttl = 255 time = 26.2 ms 64 bytes from 10.1.1.2: icmp_seq = 4 ttl = 255 time = 25.1 ms

--- 10.1.1.2 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min / avg / max = 25.1 / 26.0 / 26.5 ms

HQ # ping 192.168.254.99 HQ LAN interface PING 192.168.254.99 (192.168.254.99): 56 data bytes 64 bytes from 192.168.254.99: icmp_seq = 0 ttl = 255 time = 0.1 ms 64 bytes from 192.168.254.99: icmp_seq = 1 ttl = 255 time = 0.1 ms 64 bytes from 192.168.254.99: icmp_seq = 2 ttl = 255 time = 0.1 ms 64 bytes from 192.168.254.99: icmp_seq = 3 ttl = 255 time = 0.1 ms 64 bytes from 192.168.254.99: icmp_seq = 4 ttl = 255 time = 0.1 ms

--- 192.168.254.99 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min / avg / max = 0.1 / 0.1 / 0.1 ms

HQ # ping 192.168.247.99 LAN Branch Interface PING 192.168.247.99 (192.168.247.99): 56 data bytes

--- 192.168.247.99 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss

 

IPSEC PHASE1-INTERFACE VPN

 

HQ (VPN-HQ) # show config vpn ipsec phase1-interface edit "VPN-HQ-BRANCH" set interface "wan1" set peertype any set net-device disable set proposal aes128-sha256 aes256-sha2 set remote-gw XXX.XXX.XXX.XXX set psksecret ENC hKxNBj3XkvergUONCEoAebupp2zdo8R / 28QI0KyJn6CzoHwhf1T7Zt3VfS3sni7cW98giDScEaaZ61zbW7RTXIpiPK3hVXWHdcFZ + / PiDkY end

 

IPSEC PHASE2-INTERFACE VPN

HQ (VPN-HQ) # show config vpn ipsec phase2-interface edit "VPN-HQ-BRANCH" set phase1name "VPN-HQ-BRANCH" set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm aes256gcm chacha20poly1305 set auto-negotiate enable set src-addr-type name set dst-addr-type name set src-name "all" set dst-name "10.1.1.2/32 next end

 

Route Static

HQ (28) # get seq-num: 28 status: enable dst: 0.0.0.0 0.0.0.0 distance: 10 weight: 0 priority: 0 device: VPN-HQ comment: blackhole: disable dynamic-gateway: disable dstaddr: 10.1.1.2/32 link-monitor-example: disable bfd: disable

emnoc
Esteemed Contributor III

Okat bravo if I can make some recommendation 

 

On the remote firewall your phase2 needs to have this added on FG80

 

 

edit "VPN-HQ-BRANCH"2" set phase1name "VPN-HQ-BRANCH" set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm aes256gcm chacha20poly1305 set auto-negotiate enable set src-addr-type name set dst-addr-type name set src-name "192.168.254.0/24" set dst-name "192.168.257.0/24" next

end

 

You will also needs policyes on both firewall to  allow the 1.1.1.0s address

 

e.g 

 

config firewall address

   edit 10.1.1.0-24

      set subnet 10.1.1.0/24

   end

 

config firewall policy edit 0 set name "allow_vpn_interfaces"   set srcintf "VPN-BRANCH" set dstintf "VPN-BRANCH" set srcaddr "10.1.1.0-24" set dstaddr "10.1.1.0-24" set action accept set schedule "always" set service "PING" next end

 

Make sure the policy is high up in the seq#. I believe if you fix the phase2-config, apply a policy 10.1.1.x can ping the lan behind the remote fgt over the ipsec-interface.

 

 

For future reference when providing the cfg just do a "show" and not a "get" . The output is much easier to read imho 

 

e.g  demostration of get and show with a firewall policy

 

 

brooklyn-south (13) # get policyid : 13 status : enable name : QUIC-BROWSERS uuid : d07a8548-0360-51eb-f755-ab46572a1f7f srcintf : "lan" dstintf : "wan1" "upg-zone-wan2" srcaddr : "LAN" dstaddr : "all" srcaddr6 : dstaddr6 : internet-service : disable internet-service-src: disable reputation-minimum : 0 src-vendor-mac : rtp-nat : disable action : accept schedule : always schedule-timeout : disable service : "QUIC" tos-mask : 0x00 anti-replay : enable utm-status : disable inspection-mode : flow profile-protocol-options: default ssl-ssh-profile : no-inspection logtraffic : utm logtraffic-start : disable auto-asic-offload : enable np-acceleration : enable permit-any-host : disable permit-stun-host : disable fixedport : disable ippool : disable session-ttl : 0 vlan-cos-fwd : 255 vlan-cos-rev : 255 wccp : disable groups : users : fsso-groups : disclaimer : disable email-collect : disable natip : 0.0.0.0 0.0.0.0 diffserv-forward : disable diffserv-reverse : disable tcp-mss-sender : 0 tcp-mss-receiver : 0 comments : block-notification : disable custom-log-fields : replacemsg-override-group: srcaddr-negate : disable dstaddr-negate : disable service-negate : disable timeout-send-rst : disable captive-portal-exempt: disable dsri : disable radius-mac-auth-bypass: disable delay-tcp-npu-session: disable vlan-filter : traffic-shaper : traffic-shaper-reverse: per-ip-shaper : nat : enable

 

 

brooklyn-south (13) # show config firewall policy edit 13 set name "QUIC-BROWSERS" set uuid d07a8548-0360-51eb-f755-ab46572a1f7f set srcintf "lan" set dstintf "wan1" "upg-zone-wan2" set srcaddr "LAN" set dstaddr "all" set action accept set schedule "always" set service "QUIC" set nat enable next end

 

The latter is much easier to read and to follow , imho for just reviewing the cfg. 

 

Ken Felix

 

 

 

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Cleyton_Agenil_da_Si

Hello emnoc

Include the options indicated, but did not work, pinging the CLI for DNS windows inside FG 50E Branch box does not respond. Ping command behind FG 50E Branch at stations works perfectly.

Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors