Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Flamba
New Contributor

Help on traffic rules on vpn ipsec

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.

4 Solutions
ede_pfau
Esteemed Contributor III

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.


Ede

"Kernel panic: Aiee, killing interrupt handler!"

View solution in original post

Ede"Kernel panic: Aiee, killing interrupt handler!"
ShawnZA

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.

View solution in original post

ShawnZA

"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

 

 

 

 

 

View solution in original post

ede_pfau
Esteemed Contributor III

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.

 

 


Ede

"Kernel panic: Aiee, killing interrupt handler!"

View solution in original post

Ede"Kernel panic: Aiee, killing interrupt handler!"
8 REPLIES 8
ede_pfau
Esteemed Contributor III

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.


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
Flamba

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.

Flamba
New Contributor

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... 

ShawnZA

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.

Flamba
New Contributor

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 

ShawnZA

"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

 

 

 

 

 

ede_pfau
Esteemed Contributor III

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.

 

 


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
Flamba
New Contributor

I love you all !! <3 It works wonderfully !!!!!!!!!!

 

I had a problem in the policy routes. 

Labels
Top Kudoed Authors