Fortigate OSPF behavior

[infrasg]

Hi all

Need help in Fortigate behavior on OSPF routing

In the attached image - 

What will happen if traffic from 0.x is send to server1 via wan2 but return traffic from server1 is send via wan1 ?

Thank you

[Kangming · Accepted solution]

infrasg wrote:

Hi Kangming

Please find 2 attached - scenario1 and scenario2

scenario1 - 0.x to 1.x  (0.x to server 1 via wan2 and server1 reply via wan1)

scenario2 - 1.x to 0.x  (server1 request via wan1 and 0.x reply via wan2)

scenario1

scenario2

Why do you say that scenario2 will have issue ?

Thank you

Hi 

scenario2  

It should not be run traffic like this, FGT will keep WAN1 IN and keep WAN1 OUT.

The flow direction I mentioned is like this：

but it seems that OSPF route will not send the data like this, because the routing on the SW1/SW2 is not load balanced. So there is no problem. There are many of these situations, and they are indeed complicated. If possible, you can find a device or actually do an experiment with EVE-NG, so that you will have a deeper understanding.

So the best way is to use static routing to separate the traffic fixedly so that you can avoid doing such a complicated analysis. Various traffic directions and different situations after various asynchronous/auxiliary sessions are enabled. This is very difficult to troubleshoot, unless you are familiar with these things.

[emnoc]

Most likely dropped due to asymmetrical and stateful tracking  Do you need ECMP in this case? or can you weight traffic to just one of the /30?

btw nice diagram

Ken Felix

[infrasg]

emnoc wrote:

Most likely dropped due to asymmetrical and stateful tracking  Do you need ECMP in this case? or can you weight traffic to just one of the /30?

btw nice diagram

Ken Felix

Hi Ken

Prefer to utilize all the links but worried about asymentrical traffic 

Will enabling auxliiary session help ?

Thank you

[Kangming]

infrasg wrote:

emnoc wrote:

Most likely dropped due to asymmetrical and stateful tracking  Do you need ECMP in this case? or can you weight traffic to just one of the /30?

btw nice diagram

Ken Felix

Hi Ken

Prefer to utilize all the links but worried about asymentrical traffic 

Will enabling auxliiary session help ?

Thank you

It will be very helpful. If auxiliary-session is disabled, the traffic is passed, but the session is dirty repeatedly and cannot be offloaded by NPx. It can only be processed by the CPU. When the traffic is large, a lot of CPU resources will be consumed, and if auxiliary-session is enabled, An auxiliary session will be created so that the traffic will be offloaded by NPx.

I think this document can explain your question：

https://docs.fortinet.com/document/fortigate/6.4.4/administration-guide/014295/controlling-return-pa...

[Kangming]

Hi

192.168.0.x ---to----192.168.1.x   

In this case, the traffic will be normal. It looks like asynchronous traffic, but it is not. TCP_SYN goes out from WAN2 and TCP_SYN_ACK comes back from WAN1, there is no problem. and it can also be accelerated by NP, but it’s weird to see such traffic.

192.168.1.x---to---192.168.0.x

SYN WAN1 

SYN_ACK WAN1 reply

ACK WAN2 ---- drop

In this case, it is asynchronous traffic, it will not be connected by default, and the traffic will be blocked. 

You must try to avoid this situation, otherwise, you need to enable asynchronous traffic.

Technical Note: How the FortiGate behaves when asymmetric routing is enabled

https://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD39943&sliceId=...

[infrasg]

kmliu wrote:

Hi

192.168.0.x ---to----192.168.1.x   

In this case, the traffic will be normal. It looks like asynchronous traffic, but it is not. TCP_SYN goes out from WAN2 and TCP_SYN_ACK comes back from WAN1, there is no problem. and it can also be accelerated by NP, but it’s weird to see such traffic.

192.168.1.x---to---192.168.0.x

SYN WAN1 

SYN_ACK WAN1 reply

ACK WAN2 ---- drop

In this case, it is asynchronous traffic, it will not be connected by default, and the traffic will be blocked. 

You must try to avoid this situation, otherwise, you need to enable asynchronous traffic.

Technical Note: How the FortiGate behaves when asymmetric routing is enabled

https://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD39943&sliceId=...

Why is scenario 1 not consider as async ?

How does it differ from scenario 2 ?

Since server is pointing to local switch as gateway - if TCP_SYN is going in via WAN1 - how does ACK from 1.x go to WAN2 ?

Thank you

[Kangming]

infrasg wrote:

kmliu wrote:

Hi

192.168.0.x ---to----192.168.1.x   

In this case, the traffic will be normal. It looks like asynchronous traffic, but it is not. TCP_SYN goes out from WAN2 and TCP_SYN_ACK comes back from WAN1, there is no problem. and it can also be accelerated by NP, but it’s weird to see such traffic.

192.168.1.x---to---192.168.0.x

SYN WAN1 

SYN_ACK WAN1 reply

ACK WAN2 ---- drop

In this case, it is asynchronous traffic, the requested packet comes from different interfaces, and the traffic will be blocked. 

we must try to avoid this, otherwise, you need to enable asynchronous traffic.

Technical Note: How the FortiGate behaves when asymmetric routing is enabled

https://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD39943&sliceId=...

Why is scenario 1 not consider as async ?

How does it differ from scenario 2 ?

Since server is pointing to local switch as gateway - if TCP_SYN is going in via WAN1 - how does ACK from 1.x go to WAN2 ?

Thank you

scenario 1  because this is a reply packet from a different interface, not a request packet, this scenario is more common in some network ISP operators. This does not affect the establishment of a TCP session, and the session can be established normally. 

scenario 2 This means that the request packets come from different interfaces. At this time, the session is being established. There will be issues with the establishment of the session, which belongs to asynchronous traffic.

>Since server is pointing to local switch as gateway - if TCP_SYN is going in via WAN1 - how does ACK from 1.x go to WAN2 ?

If the SW route does not perform Load balancing, it is normal and will not be asynchronous, because FGT has the function of source input and source output by default. What I mean is to avoid such traffic, if not, it would be great.

[Kangming]

There seems to be a better solution is to specify static routes. We can still keep OSPF, just add static routes on this basis, The server static route on the WAN1 side points to the SW of WAN1, and the server static route on the WAN2 side points to the SW on the WAN2 side. If there is a better IP address plan, For example, 192.168.1.1-192.168.1.127 is on the SW on the side of WAN1, 192.168.1.128-192.168.1.254 is on the SW on the side of WAN2, it can be easily implemented.

wan1  to server1 static route 192.168.1.0/25    gw  192.168.254.2

wan2  to server2 static route 192.168.1.128/25 gw 192.168.254.6

So both WAN1 and WAN2 can be used, at the same time, there are no strange traffic lines.

This can avoid the existence of strange traffic on different lines, and effectively improve maintenance and troubleshooting.

Thank you.

[infrasg]

Hi Kangming

Please find 2 attached - scenario1 and scenario2

scenario1 - 0.x to 1.x  (0.x to server 1 via wan2 and server1 reply via wan1)

scenario2 - 1.x to 0.x  (server1 request via wan1 and 0.x reply via wan2)

scenario1

scenario2

Why do you say that scenario2 will have issue ?

Thank you

[Kangming · Accepted solution]

infrasg wrote:

Hi Kangming

Please find 2 attached - scenario1 and scenario2

scenario1 - 0.x to 1.x  (0.x to server 1 via wan2 and server1 reply via wan1)

scenario2 - 1.x to 0.x  (server1 request via wan1 and 0.x reply via wan2)

scenario1

scenario2

Why do you say that scenario2 will have issue ?

Thank you

Hi 

scenario2  

It should not be run traffic like this, FGT will keep WAN1 IN and keep WAN1 OUT.

The flow direction I mentioned is like this：

but it seems that OSPF route will not send the data like this, because the routing on the SW1/SW2 is not load balanced. So there is no problem. There are many of these situations, and they are indeed complicated. If possible, you can find a device or actually do an experiment with EVE-NG, so that you will have a deeper understanding.

So the best way is to use static routing to separate the traffic fixedly so that you can avoid doing such a complicated analysis. Various traffic directions and different situations after various asynchronous/auxiliary sessions are enabled. This is very difficult to troubleshoot, unless you are familiar with these things.