New Member

Solved

Fortigate OSPF behavior

Forum|Forum|4 years ago
September 1, 2021
2 replies
15890 views

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

Capture.JPG

Best answer by Kangming

infrasg wrote:
kmliu wrote:
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.

Hi Kangming

Appreciate your help and reply

Assuming if auxiliary session are disabled

1) can i check what are the rules of Fortigate on TCP handshake ?

TCP SYN and TCP ACK must ingress on same interface ?
Can TCP SYN ACK egress on a different port ?

2) if a TCP handshake is successfully established - does it matter if the subsequent traffic request and response of the same session egress and ingress through different interfaces on the firewall ? Is it consider just dirtied session but traffic still get send ?

3) What is EVE-NG ?

Thank you

Hi

Assuming if auxiliary session are disabled

-> 1) can i check what are the rules of Fortigate on TCP handshake ?

FGT will create a session when the packet comes in, so FGT will pay more attention to the message in the IN direction to create the session, and the interface from which the reply packet comes in is not so important, because the session has been established.

-> 2) if a TCP handshake is successfully established - does it matter if the subsequent traffic request and response of the same session egress and ingress through different interfaces on the firewall ? Is it consider just dirtied session but traffic still get send ?

After the session is established, traffic comes in from different interfaces. The session has an inbound interface and an outbound interface. If the inbound interface is wrong, the traffic will be blocked, and if the outbound interface is wrong, the session will be dirty and the CPU will be re-matched, which will consume CPU resources.

-> 3) What is EVE-NG ?

https://www.eve-ng.net/

https://www.eve-ng.net/index.php/documentation/howtos/howto-add-fortinet-images/

Can easily simulate FGT (KVM) and Cisco Router/Switches

emnoc

New Member

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

infrasgAuthor

New Member

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

Staff

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-path-with-auxiliary-session

Kangming

Staff

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=1&docTypeID=DT_KCARTICLE_1_1&dialogID=246350409&stateId=1%200%20246346975%27)

infrasgAuthor

New Member

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=1&docTypeID=DT_KCARTICLE_1_1&dialogID=246350409&stateId=1%200%20246346975%27)

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

Staff

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=1&docTypeID=DT_KCARTICLE_1_1&dialogID=246350409&stateId=1%200%20246346975%27)

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.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded