Hey all,
I'm struggling with something super simple. I'm working through the "Hub and spoke SD-WAN deployment example" in the admin guide, trying to set one up in real life. Some of the configuration elements, specifically the local and remote IPs on the tunnels is throwing me for a loop though.
in the admin guide, on the hub side, (on each tunnel interface) they're using an IP for the hub's tunnel interface IP and then a /24 network for the remote-ip:
config system interface
edit "vpn-isp-a"
set vdom "root"
set ip 10.254.0.1 255.255.255.255
set allowaccess ping
set type tunnel
set remote-ip 10.254.0.254 255.255.255.0
set interface "port2"
next
edit "vpn-isp-b"
set vdom "root"
set ip 10.254.1.1 255.255.255.255
set allowaccess ping
set type tunnel
set remote-ip 10.254.1.254 255.255.255.0
set interface "port3"
next
end
But on the spoke side they're using a completely different set of IPs on each tunnel interface, with a /32 for the remote-ip:
config system interface
edit "vpn_dc1-1"
set vdom "root"
set ip 10.255.0.2 255.255.255.255
set allowaccess ping
set type tunnel
set remote-ip 10.255.0.1 255.255.255.255
set interface "port2"
next
edit "vpn_dc1-2"
set vdom "root"
set ip 10.255.1.2 255.255.255.255
set allowaccess ping
set type tunnel
set remote-ip 10.255.1.1 255.255.255.255
set interface "port3"
next
end
Can someone explain to me how this works?
Thanks in advance!
Hello,
In FortiGate SD-WAN VPN setup, it is common to have different IP addressing configurations between the hub (central) and spoke (remote) sides. The specific IP addressing scheme chosen depends on the design and requirements of the network.
On the hub side, typically on each tunnel interface, an IP address is assigned to the hub's tunnel interface itself. This IP address serves as the local endpoint for the tunnel interface. Additionally, a /24 network is allocated as the remote IP address range. This range represents the pool of IP addresses that will be assigned to the remote (spoke) sites connecting to the hub.
On the spoke side, each tunnel interface is assigned a unique IP address using a /32 subnet mask. The /32 subnet mask denotes a single host IP address, effectively assigning a separate IP for each individual spoke site connecting to the hub.
The /32 address configuration is commonly used on the spoke side for the remote IP address. This configuration ensures that the spoke site has a specific IP address to establish a VPN connection with the hub. The /32 subnet mask designates a single host IP address, and in this case, it represents the hub's tunnel interface.
It's important to note that these IP addressing configurations are just examples, and actual IP addresses and subnet masks may vary based on the specific deployment and network design requirements. It is always recommended to refer to the Fortinet documentation, such as the admin guide, for detailed instructions and best practices specific to your FortiGate version and SD-WAN VPN setup.
Refer to the below KB article for configuration assistance:
So you've created some dynamic/dial-up VPN interfaces on your Hub. This means the hub has a single VPN tunnel/interface with which it will accept multiple connections (point-to-multipoint) from spokes.
Now you've used the interface configuration to assign some IP addresses to those tunnel interfaces. The remote IP is very important on the branch side that it points to the hub's IP address.
The remote IP on the Hub is not as important as the tunnel type is dynamic/or dial up and will accept connections from multiple hosts. However, we use an unused remote IP address in the hub's configuration so that we can inject a connected route for that subnet into the routing table. So whatever you set on the hub's remote-ip shouldn't be used by any branch IP.
Thank you both for the input!
I read through akileshc's article, but the principle is not clicking
There's more to it, but I need to get past this simple hurdle. This is a setup that i've taken over. I wasn't understanding why it was setup the way it was setup, which prompted the research and confusion.
In the prod setup, the hub and spoke tunnel interfaces are all on the same /24. They're configured as follows:
Hub local IP = 192.168.1.1/32
Hub remote IP = 192.168.1.2/24
Spoke 1 local IP = 192.168.1.3/32
Spoke 1 remote IP = 192.168.1.1/24
Spoke 2 local IP = 192.168.1.5/32
Spoke 2 remote IP = 192.168.1.1/24
Based on the example, and your comments, I'm guessing that the spoke side "remote IP" configuration should be 192.168.1.1/32 instead of 192.168.1.1/24 - Would this be a fair assessment?
Presuming the answer is yes, would it be fair to say that on the hub side, the remote IP is creating the network, but on the spoke side, it's more of a point to point thing?
To complicate the picture, some of the spokes in this setup have dual WAN connections and by extension, two tunnel interfaces...
Should spoke 3 look like this?
Spoke 3 local IP (tunnel interface1) = 192.168.1.7/32
Spoke 3 remote IP (tunnel interface1) = 192.168.1.1/32
Spoke 3 local IP (tunnel interface2) = 192.168.1.8/32
Spoke 3 remote IP (tunnel interface2) = 192.168.1.1/32
Thank you again!
Each tunnel needs to be in its own subnet. tunnel int1 can be 192.168.1.0/24 and tunnel int2 should be something else like 192.168.2.0/24
and yes branch side should be /32 for remote and local ip
Thank you for the input!!
Based on your input, it's sounding like the config should be changed as follows?
//No Change
Hub local IP = 192.168.1.1/32
Hub remote IP = 192.168.1.2/24
//Changed remote IP from a /24 to a /32
Spoke 1 local IP = 192.168.1.3/32
Spoke 1 remote IP = 192.168.1.1/32
//Changed remote IP from a /24 to a /32
Spoke 2 local IP = 192.168.1.5/32
Spoke 2 remote IP = 192.168.1.1/32
//Changed tunnel interface1 remote ip to a /32
//Changed tunnel interface2 local IP to 192.168.2.X
//Changed tunnel interface2 remote IP to 192.168.2.1/32
Spoke 3 local IP (tunnel interface1) = 192.168.1.7/32
Spoke 3 remote IP (tunnel interface1) = 192.168.1.1/32
Spoke 3 local IP (tunnel interface2) = 192.168.2.7/32
Spoke 3 remote IP (tunnel interface2) = 192.168.2.1/32
If so... How does the hub know about the IP (192.168.2.7) for tunnel interface2 at spoke 3?
Thanks in advance!
the hub has a tunnel interface2 in the 192.168.2.0/24 subnet. and it learns the spoke's remote IPs the same way it would for tunnel interface1 in the 192.168.1.0/24 subnet
I appreciate your continued input!
I think I'm getting this...
So it's sounding like the config should look something like this, yes?
Hub local IP interface1 = 192.168.1.1/32
Hub remote IP interface1 = 192.168.1.2/24
Hub local IP interface2 = 192.168.2.1/32
Hub remote IP interface2 = 192.168.2.2/24
Spoke 1 local IP = 192.168.1.3/32
Spoke 1 remote IP = 192.168.1.1/32
Spoke 2 local IP = 192.168.1.5/32
Spoke 2 remote IP = 192.168.1.1/32
Spoke 3 local IP (tunnel interface1) = 192.168.1.7/32
Spoke 3 remote IP (tunnel interface1) = 192.168.1.1/32
Spoke 3 local IP (tunnel interface2) = 192.168.2.7/32
Spoke 3 remote IP (tunnel interface2) = 192.168.2.1/32
I think I'm seeing how this works from a vpn perspective, now, too:
On the hub-side there are two dialup vpns (and thus, two tunnel interfaces), both bound to WAN1 (the only WAN interface on the Hub).
The single WAN spokes only have one tunnel, bound to their single WAN and the dual wan spokes have a tunnel, bound to each of their 2x WAN interfaces.
Looking at the hub config - it looks like the phase1 and 2 settings for the tunnels are identical, except for the PSKs.... when a dual WAN spoke phones home, does the hub just try to match the connection to each tunnel until one matches the params the spoke is sending?
thank you again for your help with this... being able to chat it out is really helping my understanding!!
Oh if your hub only has one WAN interface then you can probably get away with using two tunnel interfaces in the same subnet on spoke 3. Is spoke3 the only one with dual WAN?
With regards to your routing question, the decision is made based on routing table and policy routes (from SD_WAN). If tunnel2 is preferred it will route over tunnel2. The hub will route packets back over tunnel2 because that's where they came from.
Created on 05-24-2023 06:04 AM Edited on 05-24-2023 06:04 AM
Thank you for your input!
I've only depicted 3 spokes, but in actuality there are closer to 30.
More than half the spokes have dual WANs and the hub will too, eventually.
When i tried moving the spoke's tunnel2 interface to the hub's tunnel1 network, the interface would drop.
I see why now; I changed the interface IP, but not the tunnel settings, so the spoke's WAN2 tunnel was was keying up to WAN1.tunnel2 on the hub, but was using an ip from the hub's WAN1.tunnel1 network (DOH!).
I'm thinking this would work, while the hub has a single wan?
====Hub with one WAN interface, Spoke with 2x WAN====
//Hub WAN1
Hub Tunn.1 local IP = 192.168.1.1/32
Hub Tunn.1 remote IP = 192.168.1.2/24
//Spoke WAN1 to Hub WAN1
Spoke_3 Tunnel.1 local IP = 192.168.1.7/32
Spoke_3 Tunnel.1 remote IP = 192.168.1.1/32
//Spoke WAN2 to hub WAN1
Spoke_3 Tunnel.2 local IP = 192.168.1.8/32
Spoke_3 Tunnel.2 remote IP = 192.168.1.1/32
When the hub eventually gets a second WAN connection, the config would look like this:
====Hub with 2x WAN interfaces, Spoke with Dual WAN====
//Hub WAN1
Hub Tunn.1 local IP = 192.168.1.1/32
Hub Tunn.1 remote IP = 192.168.1.2/24
//Hub WAN2
Hub Tunn.2 local IP = 192.168.2.1/32
Hub Tunn.2 remote IP = 192.168.2.2/24
//Spoke WAN1 to Hub WAN1
Spoke_3 Tunnel.1 local IP = 192.168.1.7/32
Spoke_3 Tunnel.1 remote IP = 192.168.1.1/32
//Spoke WAN2 to hub WAN1
Spoke_3 Tunnel.2 local IP = 192.168.1.8/32
Spoke_3 Tunnel.2 remote IP = 192.168.1.1/32
//Spoke WAN1 to Hub WAN2
Spoke_3 Tunnel.3 local IP = 192.168.2.7/32
Spoke_3 Tunnel.3 remote IP = 192.168.2.1/32
//Spoke WAN2 to Hub WAN2
Spoke_3 Tunnel.4 local IP = 192.168.2.8/32
Spoke_3 Tunnel.5 remote IP = 192.168.2.1/32
Does that sound about right?
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 |
---|---|
1737 | |
1107 | |
752 | |
447 | |
240 |
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.