Skip to main content
Renoslav
Renoslav
New Member
April 16, 2024
Solved

Policy based routing to IPsec tunnel

  • April 16, 2024
  • 1 reply
  • 3780 views

I have found this article:

 

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Configure-policy-routes-for-route-based-interface/ta-p/193376

 

But it is not 100% clear to me. Static routing is no problem. But policy based is not working for me. As I understood, in policy route, I have to select "Outgoing interface" (ipsec interface) and "Gateway address". Now, when I did not fill in the GW, the policy route was skipped and only static routes was evaluated. Than I found the article stating: "The solution is to configure an 'IP' and 'Remote IP' on the virtual tunnel interface". So I did it, only on my side of tunnel, and policy route was being hit after that and also data was flowing the correct way (so it seems at least, but it is not returning back).
From the article it is not clear to me, if the IP and remote IP on interface and using gw of remote IP in policy routing is just a requirement, so the policy route is evaluated or does the remote IP have to exist in reality on remote firewall?

Thank you

Best answer by Renoslav

I just tested it against opnsense.

Fortigate 6.4: created ipsec tunnel (Tunnel search - Next-hop), used IP pool for nat, that is not mandatory here, but trying to replicate my setup. Specified Phase2 selector for testing source and destination ip. On Tunnel interface I have configured ip 10.1.1.5 and remote ip 10.1.1.6/30 (These does not exist anywhere)

On opnsense, created ipsec tunel in mode "Tunnel", so it relies on "Security Policy Database" - fed by phase2 config. Phase2 is the same as on Fortigate, just in reverse order.

 

Now, fortigate uses policy route and 10.1.1.6 as GW. This ip actualy does not exist on fortigate nor opnsense. Opnsense does not use any gw, it relies on security policy. And it works with no issues.

 

So back to article https://community.fortinet.com/t5/FortiGate/Technical-Tip-Configure-policy-routes-for-route-based-interface/ta-p/193376 it really is sufficient to set this non existing gw on tunell interface on one side, at least in this setup.

1 reply

AlexC-FTNT
Staff
AlexC-FTNT
Staff
April 16, 2024

You want the policy route to be evaluated = needs remote gateway

You want the traffic to know where to return = needs IP defined on the VPN tunnel in the remote device (otherwise it will follow the default routing in remote device, or use another IP as source and be dropped by the tunnel)

Renoslav
RenoslavAuthor
New Member
April 16, 2024

First, thank you for your reply.

 

In an ordinary network, if one device is routing traffic, it is changing mac address of destination, so the frames are delivered to correct device.
In ipsec, the packet is encapsulated, going through the tunnel and on the other and after decapsulation, it looks for its destination.


And that is what I do not understand here. When I make up remote IP (and use it as GW in policy route), it does not exist anywhere. My firewall push data to the tunnel. But IP of GW does not exist, mac address of that non existing gw is also unknown. What does it actually do? I would say, that after decapsulation on remote side, the GW IP I used is no longer relevant. Does the remote firewall even know, what IP I was using in GW field of policy route (I think not)?

 

One additional info, the remote firewall is not using policy based routing, just static routing pointing to the tunnel, so it does not need to know any gw ip.

Unfortunately, I have no other firewall I can test to see, if it actually goes through.

 

Thank you

 

 

AlexC-FTNT
Staff
AlexC-FTNT
Staff
April 16, 2024

"Does the remote firewall even know, what IP I was using in GW field of policy route (I think not)?" - probably not. But remote gateway needs to be set up as the next hop IP, per RFC. And that applies for the remote device too.
"just static routing pointing to the tunnel, so it does not need to know any gw ip." -- if that works sure. but I guess the return traffic initiated/received from the tunnel will not be sent there.

Terms & ConditionsAccessibility statement