Skip to main content
smorty11
New Member
March 2, 2022
Question

FortiGate BGP Route leaks

  • March 2, 2022
  • 6 replies
  • 11945 views

Hi, I am hoping someone may be able to help. I currently have BGP peers set up for the Internal network and then the DMZ, separate VRFs in the DC but same VRF on the FortiGate.

Servers in the DMZ currently can’t access the internal networks because they are not learning the routes so I need to leak the learned routes from the Internal BGP peers so traffic coming from the DMZ knows which way to route via the FortiGate.

I can see the DMZ traffic hitting the DMZ interface but then not traversing the firewall. IPv4 policies are in place.

I’ve been reading forums and the advice is route-maps but unsure how to go about this.

Any help would be greatly appreciated.

6 replies

akristof
Staff
Staff
March 3, 2022

Hello,

 

Thank you for your question. You can check this kb:

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Route-leaking-between-VRFs/ta-p/198702

It will show you how you can leak routes between VRFs. I think you will need to do anything on DC as it has different VRFs, on remote FortiGate no changes should be needed.

Adam19892000
New Member
March 3, 2022

Hi, I actually asked this question on Reddit yesterday which is odd. Reddit Post I’ve added some extra config. 

Could I ask a couple of questions please. 

 

At the moment I don’t have separate VRFs set up on the FortiGate. Is this a requirement? 

The link you have provided, this is specifying specific routes but the FortiGate is learning all internal routes (quite a few) via the two Internal BGP Peers. Is there a way that I can allow the DMZ to learn all these in their entirety without specifying certain routes? 

I could just put static routes of the supernets to point the traffic to the Internal ports and then a default route out to the Internet peers but trying to use BGP throughout for resilience purposes. 

 

 



 

akristof
Staff
Staff
March 4, 2022

Hi,

 

VRFs are not mandatory. It usually is design decision that you want separate some traffic, but you don't want to use vdoms.

 

And in theory yes, you can use static default route to route all traffic outside of vrf. But then the point vrf is gone. Usually you want to leak only specific routes for specific traffic.

Toshi_Esumi
SuperUser
SuperUser
March 7, 2022

By the way, why do you need to separate both sides with FGT's VRFs? Are there any route overlaps between them? Generally policies are the ones isolate DMZ from internal and external network.

 

Toshi

Adam19892000
New Member
March 14, 2022

Hi Toshi, 

 

Unsure whether this question is aimed at me but at the moment I don't have VRFs created on the FortiGate. I have VRFs configured on our ACI DC infrastructure that then connect into the FortiGate. This is where I then need to allow routes to traverse the FortiGate so the DMZ knows to route traffic internally and everything else via the Internet. I'm trying not to create VRFs on the FortiGate as well, just allow the DMZ servers to learn where to send the traffic. 

 

Adam

Toshi_Esumi
SuperUser
SuperUser
March 14, 2022

I see I misunderstood your original statement. So from FGT's view it's get a plain IP (or vlan tagged) packets from outside. Then this design has nothing to do with VRF at all.

 

Toshi

Adam19892000
New Member
March 14, 2022

Not on the VRF No. Different VLANs (on the FortiGate) providing access to specific networks with routes being learned via BGP Peers. 

 

I just need the DMZ servers to learn all the routes the FortiGate is learning from "10.9.4.17" [Internal Peer] and "10.9.4.18" [Internal Peer] and then learn the default route via "26.98.214.220" [External Peer] and "26.98.214.221" [External Peer]. 

Still trying to get my head around exactly how I configure this and I'm really trying not to just set up static routes with local preference when we're using BGP for resilience everywhere else. 

 

Adam

Toshi_Esumi
SuperUser
SuperUser
March 14, 2022

Are these iBGP or eBGP peers? If eBGPs each other, all routes coming from one side will be forwarded to all other neighbors. So I'm assuming you set the same ASN for iBGP, which would cause this kind of situation if those "DMZ" peer and "internal" peers don't be neighboring directly each others in mesh. You need to use eBGP.

 

Toshi

Adam19892000
New Member
March 14, 2022

Thanks Toshi, I didn't specify iBGP or eBGP, just used the BGP GUI to set up the peers so I assume the default is iBGP. Is there a way of changing the default so then all the current settings will switch to eBGP? 

Adam

Toshi_Esumi
SuperUser
SuperUser
March 14, 2022

For BGP config, GUI is very limited. We almost always have to configure in CLI. Most of the config is under "config router bgp" except route-maps, prefix-list and community-list. First check what's in there to see how its own ASN and neighbors' are configured. "show" will show you all once you got in the config router bgp. Then you can adjust the ASNs. But you have to change them on the peer sides as well.

Adam19892000
New Member
March 14, 2022

Will it specify whether iBGP or eBGP is used in the config? 

The other side of the BGP is Cisco ACI and uses MP-BGP so this should be fine. I would have to check with the service provider regarding the Internet peer. 

So, in theory, if I change from iBGP (which we assume is being used) to eBGP then that will automatically allow for routes to traverse or will I then have to add route-maps etc still? 

Adam

Toshi_Esumi
SuperUser
SuperUser
March 14, 2022

What makes it iBGP or eBGP is what ASN both sides of peering have. If both are like 64512, it's iBGP.  But if 64512 one side and 64513 on the other, it's eBGP.
As you said before peering with the FGT has nothing to do with MP-BGP. That's just for inside of Cisco ACI network (I think, because I have no knoledge about Cisco ACI) and peering with FGT is just one instance of VRF on the Cisco to the FGT in plain BGP. We do this between Cisco 7600 MPLS network with multiple FGT clusters.

In our case, the Cisco side has our company's public ASN then we set a private ASN on the FortiGate side (64512-65535 range). So that the peering is always eBGP.

 

Yes, when you have eBGP peering both sides advertise basically everything it has to the peer. Likely you have to filter them with route-maps.

 

You might want to get support from Cisco how to configure eBGP peering with an outside device like the FGT on the Cisco side.

 

Toshi