We have two customers who have the same issue on R80.40 VSX gateways. Both are running take 118.
The issue is with Destination NAT:ed TCP traffic (UDP not tested), specifically on a R80.40 VSX Gateway. Both customer has run R80.10 before where the issue was not present.
Traffic has a delay of 7 seconds for both customers, but the behavior in PCAP was slightly different, probably due to some SecureXL calculations. For one customer, the SYN does not pass the firewall at all. On the 4th SYN attempt from the client (7 seconds in), it finally passes through the firewall & syn-ack is received. Everything works well after that.
For the other customer, the destination NAT:ed IP is on a DMZ which is in the same range as the original destination. This destination NAT rule has a specific port as a criteria. Example: Original destination is 184.108.40.206 port 50000, translated destination is 220.127.116.11 port 50000. The PCAP shows again that on the 4th SYN, the traffic finally works. The big difference for this PCAP is that traffic is actually translated and sent out, but to the wrong MAC address. It is sent to 18.104.22.168's host MAC address, at the 4th SYN packet, it is sent to the correct MAC address.
We've debugged the issue and we can see in the Debug that on the 4th packet, SecureXL updates the MAC addresses and after the traffic flows.
Turning SecureXL off, or only for the specific traffic helps & make the session establish fast as expected.
We've got tickets open to TAC but have not received any conclusive answers, it surprises me as I would assume alot of people should have this problem. Hence I wanted to check with the community if anyone else has experienced this issue & possibly have received any fix?