Citrix SDWAN : Branch to Branch Virtual Path down because of CGNAT on the WAN link

Citrix SDWAN : Branch to Branch Virtual Path down because of CGNAT on the WAN link

book

Article ID: CTX256749

calendar_today

Updated On:

Description

The path created using a WAN link with CGNAT configured remains in dead state for Branch to Branch communication. No issues seen between Branch and MCN. Check the topology below to understand the scenario :




In the above topology, at Branch1, the LTE link is getting CGNAT by the provider i.e. the source port for the Virtual Path packets would change from 4980 to a random port when going to MCN or Branch 2. In the above topology, the port is getting changed to 23412 from 4980 when Source IP NAT happens on the CGNAT router. So when the packet would be received by the Branch 2 WAN links, by default they would not respond back on the port 23412 and will keep using port 4980 as source and destination port for the communication.

However, in case of communication with the MCN, the MCN by default dynamically learns the source IP and source port of the Branch sides, as long as we enable the option of "Autodetect Public IP" when configuring the WAN link on the Branch side. So in the above scenario, paths should come up between both the WAN links of Branch 1 and MCN. However, between Branch 1 and Branch 2, path created using the LTE link would remain down but would come up between the second WAN link (2.2.2.2) and the two WAN links of the Branch 2.

Resolution

To fix this issue, it is required to enable "UDP hole punching" for the link which is getting CGNAT on the Virtual Path between that Branch and MCN. 


For example, as shown in the above configuration, the UDP hole punching needs to be enabled on the Branch 1 LTE WAN link for the Virtual Path with MCN. Once enabled, the MCN will assist UDP connectivity between compatible NAT protected Client sites. So MCN will learn the random source port open on the Branch1 and will share the details with Branch2, so that Branch2 can initiate the packet on the correct destination port. Going by the topology diagram shown above, MCN will update Branch 2 that the IP and port on which communication should happen with Branch1's LTE link is 1.1.1.2:23412 instead of 1.1.1.2:4980

This becomes especially important in cases where the other Branch is also running a router with Dynamic NAT enabled or security policies which would allow OUT to IN traffic only if there is an IN to OUT connection entry present. For example, in the above topology, the INT Router on Branch2 is doing Dynamic NAT and would allow OUT to IN connections only if the IN to OUT entry is present. So any connections from 1.1.1.2:23412 >> 10.4.4.2:4980 would only be allowed if there is already an entry present for 10.4.4.2:4980 >> 1.1.1.2:23412. So the packets coming from source IP 1.1.1.2:23412 would not even reach IP 10.4.4.2. The IN to OUT entry would not be formed as the Branch2 would keep accessing the Branch 1 on port 4980. Enabling UDP hole punching would make the MCN inform the Branch2 about the correct port and IN to OUT entry would be created.

Please note that sometimes, even after enabling the UDP hole punching the Branch2 might still keep on using port 4980 as the destination port instead of the correct port. This happens in scenarios where the Branches have started to communicate with MCN and the UDP hole punching is enabled after the communication starts, then the Public IP and port details table is incorrectly updated causing the paths to be in dead state due to missing table re-updation post UDP hole punching changes. 

Essentially to workaround is to restart the MCN's Virtual WAN service so that MCN corrects the details and repopulates the database and shares the correct details with the other Branches. This specific issue is expected to be fixed from 11.x build.

RECOMMENDATION : It is recommended that in cases where the branches do get CGNAT, then it is better to enable UDP Hole punching as part of the configuration firsthand before activating Virtual Paths.

Additional Information

More details about UDP hole punching can be checked on Wikipedia :

https://en.wikipedia.org/wiki/UDP_hole_punching