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?
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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.
I think we should take a step back and identify what is NOT working?
Ken Felix
PCNSE
NSE
StrongSwan
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.
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
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
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.
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
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
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1696 | |
1092 | |
752 | |
446 | |
228 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.