Hello,
I would like to ask some advise and recommendations as well with our Site-to-Site IPSEC VPN.
Below are the scenarios. Please refer on the attached diagram.
We have an existing Site-to-Site IPSEC which is Site A going to Site C. Since we are expanding our site, we are creating a new site which is site B. The problem is, it has the same IP segment, 192.168.18.xx.
[strike]Also, our main goal is to be able to communicate site A and site B without changing the IP Networks on both sites. Meaning, we will use 192.168.18.xxx on both sites. Is it possible?[/strike] Already achieved this goal.
Next, let's say we were able to achieve our main goal above. [strike]Our next goal is to be able to communicate site B to site C without changing configurations on site A to site C which is our existing site-to-site IPSEC.[/strike] Mission complete. :D
Thank You.
Solved! Go to Solution.
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.
Looking at your diagram, it's not the same subnet on site A and site B, because of the subnet mask /27. So you don't have any issues at all, otherwise you could use a link network with a different IP range, like this:
Site A: 192.168.18.0 -> NAT to -> 192.168.19.0
Site B: 192.168.18.0 -> NAT to -> 192.168.20.0
If you want to connect from site Site A to Site B for example, you would use the 192.168.20.0 destination address
Edit: There are several articles on the KB, here is one example with overlapping subnets and site to site VPN:
oheigl wrote:Hello, We were able to communicate the PC1 and PC2 on Site A and Site B through IPSEC. Now, our next problem is how to be able to communicate the PC2 in Site B to the server farm through Site A and Site C.Looking at your diagram, it's not the same subnet on site A and site B, because of the subnet mask /27. So you don't have any issues at all, otherwise you could use a link network with a different IP range, like this:
Site A: 192.168.18.0 -> NAT to -> 192.168.19.0
Site B: 192.168.18.0 -> NAT to -> 192.168.20.0
If you want to connect from site Site A to Site B for example, you would use the 192.168.20.0 destination address
Edit: There are several articles on the KB, here is one example with overlapping subnets and site to site VPN:
Have you checked the routing and policies? Site C FortiGate needs a route through Site A for the local network in Site B. The easiest way to find out where the packets are not forwarded correctly is to start an endless ping on PC2:
ping <serverfarmip> -t
After that, start the following command on all FortiGates, and see on which FortiGate the ping is not being forwarded (no out interface):
diag sniffer packet any 'host <PC2ip> and host <Serverfarmip>' 4 0 1
You should always see one entry for the incoming packet, and one entry for the outgoing forwarded packet. If there is no out entry, check the policy and routing settings on this unit. If it's still not working, post the sniffer logs and maybe routing tables and so on, so we can figure out what's wrong
oheigl wrote:Haven't set up the routing and policy yet on Site B to Site C since we are looking on how can we route it on the second firewall on site A (the one who has IP 10.10.10.2). Since Site A and Site C has an existing route and able to communicate from PC1 of site A to Server Farm on Site C. For now below are working.Have you checked the routing and policies? Site C FortiGate needs a route through Site A for the local network in Site B. The easiest way to find out where the packets are not forwarded correctly is to start an endless ping on PC2:
ping <serverfarmip> -t
After that, start the following command on all FortiGates, and see on which FortiGate the ping is not being forwarded (no out interface):
diag sniffer packet any 'host <PC2ip> and host <Serverfarmip>' 4 0 1
You should always see one entry for the incoming packet, and one entry for the outgoing forwarded packet. If there is no out entry, check the policy and routing settings on this unit. If it's still not working, post the sniffer logs and maybe routing tables and so on, so we can figure out what's wrong
Site A (second firewall with IP 10.10.10.1) to Site C (with IP 10.10.10.2) via IPSEC
Site B to Site A (first firewall with IP 10.10.10.5 and 10.10.10.1) via IPSEC Remaining is Site B to Site C passing through the first Firewall of Site A via IPSEC then passing to the second Firewall of Site A, then passing through the Site C firewall via IPSEC.
Okay, so you need the following routes:
Firewall 2: 192.168.18.32/27 via 10.10.10.1
Firewall 4: 192.168.18.32/27 via IPsec
and the corresponding policies
oheigl wrote:Firewall 2: 192.168.18.32/27 via 10.10.10.1Okay, so you need the following routes:
Firewall 2: 192.168.18.32/27 via 10.10.10.1
Firewall 4: 192.168.18.32/27 via IPsec
and the corresponding policies
-> We already have that in Firewall 2.
Question: How can PC2 pass through Firewall 2 and Firewall 3?
Existing Route: (PC2 to PC 1) Firewall 3: 192.168.18.0/27 via 10.10.10.5 (IPSEC)
Firewall 1: 192.168.18.32/27 via 10.10.10.6 (IPSEC)
Existing Route: (PC1 to Server Farm) Firewall 2: 192.168.18.0/27 via 10.10.10.1 (Point to Point - not IPSEC) Firewall 1: 192.168.18.0/27 (Policy Route) via 10.10.10.2
On Firewall 3, do you have a route for the server farm network? It would be easier if you could post every routing configuration from all your FortiGates, like this:
show router static
Otherwise we will message back and forward 10x
oheigl wrote:I haven't started any config yet for our last goal which is to communicate PC2 going to Server Farm.On Firewall 3, do you have a route for the server farm network? It would be easier if you could post every routing configuration from all your FortiGates, like this:
show router static
Otherwise we will message back and forward 10x
I'm not sure what or who will I route from Firewall 3. As you requested, please see our static routing on the attached file.
Above is from Firewall 2 and the bottom is from Firewall 1.
None of the above is relevant unless the routes are configured in interface mode. If you're using policy based VPNs (type IPSec), stop here.
Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com
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 |
---|---|
1732 | |
1105 | |
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.