Click to set custom HTML
0 Comments
Click to set custom HTML
This post is to summarize the steps how to create VPN tunnels using Fortigate.
Related Post:
Create A Route Based VPN between FGs Using Wizard
From CLI, using Show System Interface ? to get DHCP IP on Port 1. Then use browser to open Web UI to log in with admin account. Password is null.
1. Create a basic FG vpn to FG vpn
On FG1 , create tunnel FG1-FG2
All changes on the firewall:
Policy :
Static Routes:
A New Tunnel Interface on WAN Port:
Objects and Object Groups:
VPN:
1 Create VPN using Custom Wizard Assign IP Address to Your tunnel interface. Please note if you are using a permanent evaluation license, your interface will be limited to only three, which also counts in your tunnel interface. If you exceeded the 3 limitation, the extra interface such as your tunnel interface, the configured ip address will be lost after a reboot. 2 Create Security Policies Rules to allow VPN Traffic Make sure the rules are coverning bidirection. (Optional) Best Practice: Create another route with the same Destination, but change the Administrative Distance to 200 and for Interface, select Blackhole. This is a best practice for route-based IPsec VPN tunnels because it ensures traffic for the remote FortiGate's subnet is not sent using the default route in the event that the IPsec tunnel goes down. 3 Enable BGP on Tunnel Interface Configure Local BGP Options for Fortigate 1: Local AS number: 65511 Router ID: (BGP ID) 192.168.1.1 (VTI IP) Neighbor: Remote Peer BGP ID and Remote AS number: 192.168.1.2 65512 4 Test Check BGP status:
DiagDiag BGP commands
Diag VPN Tunnel commands
Diag BGP Traffic flow# diagnose debug reset # diagnose debug disable # diagnose debug flow filter clear # diagnose debug flow trace stop
# diagnose debug flow filter port 179 # diagnose debug flow show function-name enable # diagnose debug flow trace start 454545 # diagnose debug flow show iprope enable # diagnose debug console timestamp enable # diagnose debug enable
To stop debugging.
# diagnose debug disable # diagnose debug reset # diagnose debug flow filter clear # diagnose debug flow trace stop VideosPolicy Based VPN vs Route Based VPN
By default they are route based VPNs on FGTs, you should notice in the feature visibility that policy based VPNs are disabled by default. You can use all 0s in the selectors and let your routing handle what gets passed to the routed VPN tunnel interface and ultimately encrypted (most scalable option).
Encryption domains (sometime, in route bassed vpn , it can be set to 0.0.0.0/0) have a variety of names, encryption domains, IP selectors, crypto maps, Proxy IDs, etc. What they do is define which IP addresses are allowed to pass down the VPN tunnel. The main difference in the FortiGate between route based VPNs and policy based VPNs is that policy based VPNs generally use the phase 2 selectors to determine whether traffic should be forwarded down the VPN tunnel. Route based VPNs use routing to determine whether to forward the traffic into the VPN tunnel. A simple way to think of them when working with route based VPNs is that they are a final ACL for whether traffic can use the VPN. So even if you forward a packet into the VPN, if it doesn't meet the selectors, it won't forward.
As a note, you can use a route based VPN on one end, and a policy based VPN on the other end. This often happens with Cisco ASAs (policy based) to FortiGates (commonly deployed as route based). The important part is that as long as the IP selectors match, everything should work fine. ASAs crypto maps are normally narrow, so the FortiGate normally has some form of IP selector defined.
General advice on VPNs: (from https://www.reddit.com/r/fortinet/comments/13i7jdm/eli5_routebased_vs_policybased/)
Policy-based IPSec is the IPSec variety that most customer's are familiar with. If you haven't changed the mode to VTI, the device is building a policy-based tunnel. Policy-based IPSec has the following characteristics:
VTI (route-based) IPSec is supported by most security appliance providers and is the default option for some. VTI does not rely on a tunnel policy to define interesting traffic. Rather, a tunnel interface is created that behaves similarly to any other non-tunnel interface. Below is a fuller description of VTI's characteristics:
Note: https://customer.cradlepoint.com/s/article/What-is-the-difference-between-VTI-and-policy-based-IPSec
Policy-based or VTI (route-based): Which to use?
For connecting multiple sites with unique subnets in a simple hub-and-spoke VPN topology, policy-based IPSec should be sufficient. Such a topology is illustrated below (note that there is no subnet overlap in the policy-based topology): VTI is the recommended solution for creating a VPN mesh (partial or full) or when overlapping subnets are used. Such a topology is illustrated below: References
Click to set custom HTML
Click to set custom HTML
Click to set custom HTML
Click to set custom HTML
|
|