Hello to all dear friends!
I'm running out of ideas to do a job that is simple but it puts me in trouble.
I would like to understand with you which best practices i can use.
In practice, i have a Fortigate 100d with a local network 192.168.1.0/24 on port 1 , which is the main network. To make my users work in terminal servers, a tenant is asking me to create a VPN with another network behind a watchguard in subnet: 10.150.5.0/24 where is the server we need to reach. I have to deny everything that can come from the other network (10.150.5.0/24) to mine.
I'm running out of ideas or best practices ...
can you help me ?
thank you all.
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.
FortiOS makes that easy for you: if you don't explicitely allow traffic from one interface to another, there will be not traffic. In other words, just create a policy which is outbound from your side (site), and no inbound policy at all. That's all.
If I understand correctly then I think you would need to create a IP Pool for the range that the traffic would need to come from, the range you mentioned.
Then in the rule enable NAT and select "Use dynamic IP Pool" and select the pool you created.
"watchguard expects the requests to come from a network in 10.0.4.0/24"
Overload should work, and add one IP in the pool our of the range, here is an example:
Replace the 1.1.1.1 with lets say 10.0.4.20 (you need to ask the guys that is in charge of the Watchguard if you can use any IP in that 10.0.4.0/24 range, or else ask them to give you one to use.
https://www.mirazon.com/h...ip-pools-in-fortigate/
If it does not work perhaps the issue is on the watchguard side...
Here is also a similar post that was solved
https://forum.fortinet.com/tm.aspx?m=159391
1- overload will do nicely. It maps the source addresses to the address(es) in the IP pool in a round robin fashion. In fact, as ShawnZA has mentioned, one single address in the pool will do. Just reserve it on your side so that it isn't used by a host.
In the outbound policy (LAN -> tunnel), check "enable NAT", "dynamic pool" and select the IP pool.
Make sure that on the WG side the source addresses allowed match your setting.
Note that traffic from FGT to WG will work fine, with reply traffic routed back to the host behind the FGT. But in the other direction, from WG to FGT, you cannot use the fake addresses as destinations - you cannot initiate connections from the WG side.
Lastly, do NOT check "port forward" in the NAT settings in the policy unless you have to! In port forwarding, you cannot use ping to test the connection.
FortiOS makes that easy for you: if you don't explicitely allow traffic from one interface to another, there will be not traffic. In other words, just create a policy which is outbound from your side (site), and no inbound policy at all. That's all.
Thank you very much ede. At the moment we have the situation pending because whoever has to configure the watchguard is on vacation.
I keep you updated.
Happy New Year to all!
With some difficulty now the VPN tunnel between the fortinet 100d and the watchguard is up!
Now i have another stupid problem to solve. I have to communicate with a server behind the watchguard that has 10.150.5.0/24 as ip and unfortunately the watchguard expects the requests to come from a network in 10.0.4.0/24... My LAN behind the Forti has a network interface on the port1 in 192.168.1.0/24... ... :( any ideas ... ? I got a headache...
If I understand correctly then I think you would need to create a IP Pool for the range that the traffic would need to come from, the range you mentioned.
Then in the rule enable NAT and select "Use dynamic IP Pool" and select the pool you created.
I am heartened by this fact because before i was trying just in this way :) unfortunately, however, I was unable to make it work. how should i set up the ip pool?
Type: Overload - One-to-one - Fixed Port Range - Port Block Allocation
"watchguard expects the requests to come from a network in 10.0.4.0/24"
Overload should work, and add one IP in the pool our of the range, here is an example:
Replace the 1.1.1.1 with lets say 10.0.4.20 (you need to ask the guys that is in charge of the Watchguard if you can use any IP in that 10.0.4.0/24 range, or else ask them to give you one to use.
https://www.mirazon.com/h...ip-pools-in-fortigate/
If it does not work perhaps the issue is on the watchguard side...
Here is also a similar post that was solved
https://forum.fortinet.com/tm.aspx?m=159391
1- overload will do nicely. It maps the source addresses to the address(es) in the IP pool in a round robin fashion. In fact, as ShawnZA has mentioned, one single address in the pool will do. Just reserve it on your side so that it isn't used by a host.
In the outbound policy (LAN -> tunnel), check "enable NAT", "dynamic pool" and select the IP pool.
Make sure that on the WG side the source addresses allowed match your setting.
Note that traffic from FGT to WG will work fine, with reply traffic routed back to the host behind the FGT. But in the other direction, from WG to FGT, you cannot use the fake addresses as destinations - you cannot initiate connections from the WG side.
Lastly, do NOT check "port forward" in the NAT settings in the policy unless you have to! In port forwarding, you cannot use ping to test the connection.
I love you all !! <3 It works wonderfully !!!!!!!!!!
I had a problem in the policy routes.
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 |
---|---|
1714 | |
1093 | |
752 | |
447 | |
232 |
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.