Incompatibility between Double NAT and Hairpinning #151
Description
Description
This bug occurs in the system tests, under the following conditions:
- Double NAT is enabled
- Both peers are behind the same NAT
- The NAT facing the private network has A(P)DM mapping behaviour
The bug results in a relay connection between the peers, while a direct connection is expected in most NAT combinations that satisfy the third condition.
How to reproduce
The following test case command produces the bug:
run_system_test -2 TS_PASS_DIRECT private1_peer1:double1:router1:private1_peer2 1-0:0-0 wg0/
To run this test, first store the above line in a file called e.g. "bug.txt" located inside the test_suite directory. Then, execute the command ./system_tests.sh -2 -f bug.txt.
Root cause
I believe the bug occurs because NAT hairpinning is implemented in the test suite by dynamically adding nftables rules upon the creation of a new session. With Double NAT where the private-facing NAT is A(P)DM, the packet that is responsible for creating a new session must also be hairpinned immediately, but this does not happen because of a delay in adding the nftables rules. Even after the nftables rules have been added, UDP hole punching still fails. It seems that the public-facing NAT which should perform hairpinning in this scenario remembers the session created by the packet that was not properly hairpinned, and all subsequent packets in the UDP hole punching process are also linked to this session.