Helpful ReplyHot!Fortigate OSPF behavior

Author
infrasg
New Member
  • Total Posts : 8
  • Scores: 0
  • Reward points: 0
  • Joined: 2021/04/30 00:01:24
  • Status: offline
2021/08/31 20:21:46 (permalink)
0

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

Attached Image(s)

#1
emnoc
Expert Member
  • Total Posts : 6210
  • Scores: 435
  • Reward points: 0
  • Joined: 2008/03/20 13:30:33
  • Location: AUSTIN TX AREA
  • Status: offline
Re: Fortigate OSPF behavior 2021/08/31 20:58:16 (permalink)
0
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  
#2
Kangming
Bronze Member
  • Total Posts : 52
  • Scores: 2
  • Reward points: 0
  • Joined: 2018/09/17 18:55:22
  • Status: offline
Re: Fortigate OSPF behavior 2021/09/02 00:07:33 (permalink)
0
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)
 
#3
infrasg
New Member
  • Total Posts : 8
  • Scores: 0
  • Reward points: 0
  • Joined: 2021/04/30 00:01:24
  • Status: offline
Re: Fortigate OSPF behavior 2021/09/02 04:22:52 (permalink)
0
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




Hi Ken
 
Prefer to utilize all the links but worried about asymentrical traffic 
 
Will enabling auxliiary session help ?
 
Thank you
#4
infrasg
New Member
  • Total Posts : 8
  • Scores: 0
  • Reward points: 0
  • Joined: 2021/04/30 00:01:24
  • Status: offline
Re: Fortigate OSPF behavior 2021/09/02 04:54:15 (permalink)
0
kmliu
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
#5
Kangming
Bronze Member
  • Total Posts : 52
  • Scores: 2
  • Reward points: 0
  • Joined: 2018/09/17 18:55:22
  • Status: offline
Re: Fortigate OSPF behavior 2021/09/02 09:48:17 (permalink)
0
infrasg
kmliu
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.
post edited by LiuKangming_FTNT - 2021/09/02 09:50:45
#6
Kangming
Bronze Member
  • Total Posts : 52
  • Scores: 2
  • Reward points: 0
  • Joined: 2018/09/17 18:55:22
  • Status: offline
Re: Fortigate OSPF behavior 2021/09/02 10:23:05 (permalink)
0
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.
#7
Kangming
Bronze Member
  • Total Posts : 52
  • Scores: 2
  • Reward points: 0
  • Joined: 2018/09/17 18:55:22
  • Status: offline
Re: Fortigate OSPF behavior 2021/09/02 16:49:37 (permalink)
0
infrasg
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




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
 
#8
infrasg
New Member
  • Total Posts : 8
  • Scores: 0
  • Reward points: 0
  • Joined: 2021/04/30 00:01:24
  • Status: offline
Re: Fortigate OSPF behavior 2021/09/02 22:43:41 (permalink)
0
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
#9
Kangming
Bronze Member
  • Total Posts : 52
  • Scores: 2
  • Reward points: 0
  • Joined: 2018/09/17 18:55:22
  • Status: offline
Re: Fortigate OSPF behavior 2021/09/02 23:06:53 (permalink) ☄ Helpfulby infrasg 2021/09/06 20:15:49
0
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


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.
#10
infrasg
New Member
  • Total Posts : 8
  • Scores: 0
  • Reward points: 0
  • Joined: 2021/04/30 00:01:24
  • Status: offline
Re: Fortigate OSPF behavior 2021/09/06 20:27:31 (permalink)
0
kmliu
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


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
#11
Kangming
Bronze Member
  • Total Posts : 52
  • Scores: 2
  • Reward points: 0
  • Joined: 2018/09/17 18:55:22
  • Status: offline
Re: Fortigate OSPF behavior 2021/09/08 12:04:25 (permalink) ☄ Helpfulby emnoc 2021/09/08 13:31:40
0
infrasg
kmliu
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


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
#12
Jump to:
© 2021 APG vNext Commercial Version 5.5