Packet duplication not done in session return packets

Forum|Forum|2 years ago
April 11, 2024
5 replies
3115 views

FortiGate 7.4.3 using both VM and 60F platforms.

I set up two tunnels in a zone with duplication=force outbound and de-duplication enable inbound. On the origination side, outbound packets are duplicated on both tunnels and are de-duplicated on receiving end. This works both ways. However, if I ping or try a TCP connection, the response packets sent from the other end are not duplicated.

I ran the Debug Flow and it clearly states in the log if it is duplicating or not, and for established sessions for "return" traffic it always picks the input interface of the session to send the data to, and does not take the extra step to duplicate to the other zone member.

Is this by design, a bug, or a configuration error? I scoured config flags to see what is related to duplication and found nothing there.

FortiGate

Best answer by ssudhakar

Hello there :

The duplication works only in original direction.

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Packet-duplication-in-SD-WAN/ta-p/258997

Hope that helps!

ssudhakarAnswer

Staff

Hello there :

The duplication works only in original direction.

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Packet-duplication-in-SD-WAN/ta-p/258997

Hope that helps!

themanyandonlyglennAuthor

New Member

I appreciate the response and I read that tech tip before. I am uncertain then as to the usefulness of this feature unless one is only streaming UDP. I was hoping this feature would give us resiliency with no outage. If the receiver is randomly picking the ingress link (I suppose whoever arrives first) for that ping or TCP connection etc, and that link happens to get cut, then replies are lost until we recognize the tunnel is down and all sessions are on the other tunnel.

Heifinator

New Member

Did anyone ever figure out if its possible to ensure return traffic is also duplicated, or at the very least returned on the same interface it was accepted on.

If we have two WANs and a session is established on WAN 1, if we are duplicating over both WANs to our hub (spoke to hub session) and WAN 1 fails. Packets will continue to flow into the hub on WAN 2, but be returned on the dead WAN 1 until DPD tears thte tunnel down.

This completely defeat the purpose of duplication. What am I missing here?

Mike-GCS

Visitor III

I would also like some clarification on this subject. At the moment, I can see the only possible use case is to smooth out the latency be accepting the first packet.

How would I achieve a goal such as Peplink's Speed Fusion? I assume I would need SD-WAN and Packet duplication enabled on both sides (Hub and Spoke).