NG Firewall, Barracuda Firewall, all versions.
This message indicates that a TCP SYN followed by a TCP ACK has been detected, without the firewall having seen the TCP SYN-ACK from the destination host. This implies that a routing triangle exists in the logical network topology that causes the firewall to only see one side of a conversation. When this routing misconfiguration exists, it will cause connections between the affected networks to either not work, or to only work in one direction.
Typically, this problem occurs when the firewall is defined as the default gateway IP address for systems on the LAN, and there exists a separate routing device connected to the same LAN that has connections to other networks. Often this is seen on networks with a private MPLS router for WAN sites. Please refer to the diagram below for an example of one such design that creates a triangular routing problem:
How do you prevent / fix this?
There are several ways to correct this.
- One solution is to configure static routes on all the systems on the LAN that tell those devices to use the correct gateway address to reach the remote network.
- Another option is to change the network configuration so that the MPLS router in the above example is not connected to the same LAN subnet as the client systems, possibly connecting to an alternate network interface on the NG.
- Yet another option would be to add an additional core routing device on the LAN that would become the default gateway of the client systems, and this core router would then be the device that decides whether traffic should go to the internet firewall, or to the internal private router.
There is also a workaround technique, sometimes described as 'hairpinning' through the firewall. The concept is to not modify the network topology design at all, but instead to create a forwarding rule on the firewall that applies source address translation on the traffic coming from the local LAN that has the destination of the remote private network. This causes the reply traffic coming back from the private router to go to the firewall, instead of returning directly to the originating LAN client. This causes the traffic between the local LAN hosts and the remote private network to take what amounts to a 'detour' through the firewall and make a 'hairpin' turn. This fix only works if the traffic is always being originated from the local LAN segment. If the remote network needs the capability to initiate connections to the local network, then 'hairpinning' through the firewall will not be useful at all. In addition, this workaround is really inefficient because it routes traffic through the firewall that should not be routed that way, putting extra load on the device.
The best fix is to modify the network topology so that these route triangles do not exist.
Link to This Page: