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

Fortigate OSPF behavior

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

2 Solutions
Kangming

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.

Thanks

Kangming

View solution in original post

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

Thanks

Kangming

View solution in original post

11 REPLIES 11
emnoc
Esteemed Contributor III

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

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
infrasg
New Contributor

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...

 

Thanks

Kangming

Kangming
Staff
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=...

 

Thanks

Kangming

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.

Thanks

Kangming

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.

Thanks

Kangming

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

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.

Thanks

Kangming

Labels
Top Kudoed Authors