Fortinet 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
infrasg

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

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