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

Policy routing over IPSEC VPN

I'm having trouble with policy routes that use an IPSEC VPN as the outgoing interface. I'll try to provide an explanation as to why I'm doing this; if there's an easier way to do what I'm trying to do, maybe someone can point me in the right direction.

 

I have a simple hub-and-spoke topology, with my office as the hub. There are IPSEC VPN tunnels to different sites, and many of these sites use the same subnets (like 192.168.10.0/24). At this time, it is not feasible to change the IP scheme at each remote site to avoid conflicts. Since each of these remotes sites accesses a different subnet at my location, I thought policy routes would be an appropriate way route this traffic correctly. For example, Site A uses 192.168.10.0/24, and they access 10.1.1.0/24 at the hub. Site B might also be using 192.168.10.0/24, but they access 10.2.2.0/24 at the hub. Policy routes seemed like a good solution, since I could route traffic from 10.1.1.10/24 to Site A, and 10.2.2.0/24 to Site B, since the source IP would always be unique.

 

This is already working for one site, which I'll call site C. However, site C connects to my location via metropolitan ethernet, not a VPN tunnel. Site C utilizes 192.168.2.0/24, which conflicts with a local subnet at the hub. I created a policy route that sends traffic from 10.3.3.0/24 (local network at the hub) to 192.168.2.0/24 using a gateway address on the MoE circuit, and that works as intended; the traffic gets to site C, and not to the local 192.168.2.0 network. I assumed I could do the same for the sites connecting via VPN, but so far have had no success.

 

When I debug the traffic flow, I can see that the policy route simply isn't being matched when the outgoing interface is a VPN. Instead, it's matching the default route and being sent out the WAN. I've tried leaving the gateway address as 0.0.0.0, using my WAN next-hop address as the gateway address, and even using the address of the remote IPSEC gateway. No matter what I put there, if the outgoing interface is an IPSEC VPN, the policy route gets ignored.

 

So the tl;dr version of this is: is it possible to use an IPsec VPN tunnel as the outgoing interface in a policy route? If so, what address to I use as the gateway address?

 

The hub site is a Fortigate 500E running 6.0.1. The IPSec tunnels themselves work fine - while using static routes I can send traffic over the vpn with no issues. And these are interface-based VPNs, not policy-based VPNs. I'm happy to provide any additional information that'll help.

 

 

Thanks everyone,

 

Andrew

9 REPLIES 9
ede_pfau
Esteemed Contributor III

Well....even after re-reading a couple of times I don't get it quite how your LANs are set up. But, fortunately, that won't matter much. (a diagram would help wonders).

If you need a gateway address you can attach addresses (which you can choose freely) to a VPN tunnel near end and remote end. They are not required for operation but in this case it might help.


Ede

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

Update with simple diagram. I'll try to keep it simple, so let's ignore site C.

 

 I want to route 10.1.1.0/24 to site A, and 10.2.2.0/24 to site B. Is it possible to do this with policy routes?

 

 

Thanks!

 

Andrew

emnoc
Esteemed Contributor III

You can't cheat and cut corners, change the remote-subnets and do it  right. PBR is not going to really help you hear and in the return traffic  that comes back to your lans

 

Alternative would be a SNAT at the remove locations if that is even feasible.

 

Ken

 

PCNSE 

NSE 

StrongSwan  

krausen
New Contributor

As I said, changing the remote IPs isn't a feasible solution.

 

Maybe I'm confused about the purpose of policy routing. Is the purpose not to route traffic based on the source address as well as the destination? This seems to be exactly what it's designed for. And I'm even using it do that right now, it just doesn't work when the outgoing interface is a VPN tunnel.

 

 

Toshi_Esumi
Esteemed Contributor

If the access happens only from spoke to hub, SNAT on the spoke side that emnoc/Ken suggested is the best option. It would hide 192.168.10.0/24 and all use the same IP you configured on the VPN interface. But if access from hub to spoke is necessary (means hub needs to reach individual devices at spoke like you're trying now --- I'm guessing you're trying to ping from 10.1.1.0/24 and 10.2.2.0/24), you have to use PBR or another complicated was like split the hub FGT into multiple vdoms.

If you use PBR, you have to have same route to 192.168.10.0/24 toward those three outgoing interfaces. Othewise, it wouldn't work.

Although I don't recommend, if you split internal interfaces for each 10.x.y.0/24 into individual vdom, and those vdoms have each IPsec vpn termination only to one of three spokes, but they're aggregated through root vdom to use the same physical interface, you don't have to worry about subnet overlaps. The complicated part is you have to set up inter-vdom links to let 10.x.y.0/24s talk each others, not only to route VPNs via root vdom.

 

Sometimes, although it could be tough, you have to say "No, it's not possible or at least extremely troublesome if we do that." to whom is pushing this.

ede_pfau
Esteemed Contributor III

Have you tried yet to use numbered VPN interfaces, like I've posted?

Besides, I fully support the opinions already voiced about a redesign.


Ede

"Kernel panic: Aiee, killing interrupt handler!"
emnoc
Esteemed Contributor III

Also does  PBR  maintain relationship  for in/out originations? So what that means, a spoke that originate traffic to a subnet overlapped does the fortigate maintain that relationship to the  SRC and SRC-interface?

 

A redesign would fix your issues 101% and eliminate  PBR to begin with.

 

Ken

 

PCNSE 

NSE 

StrongSwan  

sw2090
Honored Contributor

krausen:

 

Do I get you right?

 

You have one Hub or HQ (your office) and several sites that are connected via vpn using Fortigates. The Sites and the HQ use the same subnet.

 

This is a case I recently read on one of the Fortinet Forums and also a case I once had myself at work.

Policy routing won't help you here. You need to do mapping via VIP to be able to access anything at the remote side or vice versa. Plus you would have to use the mapped ips then.

 

There is a KB Article on that: http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD33872&sliceId=1... (this will work with FOS 5.4 or newer)

 

Also there is some Cookbook entry: https://cookbook.fortinet.com/vpn-overlapping-subnets/ (will only work with FOS >= 5.2).

 

This did the trick here...

-- 

"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams

nithin
New Contributor

Krausen,

 

Were you able to solve this issue using PBR?

 

-Nithin