v18 -> v20 hosted

[compodif]

Hi everyone,

I am currently trying to migrate our on-premise 3CX instance from v18 to v20 (deployed on a new VMware Debian 12 VM).

During our maintenance window, we assigned the production IP (172.16.0.200) to the new v20 machine and connected it to the exact same switch port as the old v18 server. Internal provisioning works fine (local Yealink T54W and W90DM base stations can reach the server on port 5060), but external communications are completely broken.

Here is the behavior of the Firewall Checker on the v20 machine:

1. Initially: All ports returned failed / not reachable.
2. After clearing the ARP cache on our SonicWall firewall: The ports became reachable, but the Firewall Checker now fails with strict NAT mapping errors:
   • testing port 5060... Mapping does not match 5060. Mapping is 62153.
   • testing port 5090... Mapping does not match 5090. Mapping is 50646.
   • testing ports [9000..9398]... failed.
3. Shortly after: Running the firewall test again caused all ports to drop back to failed / not reachable, likely because the SonicWall interpreted the aggressive UDP port scanning from the Firewall Checker as a flood/port scan attack and temporarily banned the IP.

The mystery: If we turn off the v20 VM and boot the old v18 VM back up on the exact same IP (.200), everything works instantly, the SIP Trunk registers, and external calls work perfectly.

Since I don't have administrative access to the SonicWall firewall right now (managed by an external MSP), I suspect the firewall treats the new v20 VM differently because of its new MAC address, thus enforcing symmetric/asymmetric NAT instead of a 1:1 mapped NAT.

I plan to ask our MSP to:

• Enable Consistent NAT for the 3CX IP object.
• Disable SIP Transformations (SIP ALG).
• Clear the UDP connection monitor.

Does this sound like the correct approach for a SonicWall environment transitioning to v20? Is there anything else specific to Debian 12 / v20 network stacks that could cause the firewall to alter outbound source ports compared to v18?

Thanks for your help!

 

[Kevin Attard Compagno]

If you run the firewall checker on the old v18 VM, and the firewall checker reports no issues, then yes, it's almost certainly the firewall treating the new VM differently. If you virtualization platform allows it, you could temporarily assign the old VM's MAC Address to the new VM and check it out.

Make sure that you do not have 2 machines with the same MAC Address running simultaneously

 

[compodif]

yes v18 is working perfectly

 

[Alphabetic]

It could be stored in the ARP Cache or the entry has been added as a static ARP entry on the SW. The default timeout for ARP entry is 10 minutes. It could also be the security on the SW thinking its a spoof attack - they would be faster checking the packet monitor on the SW to see why traffic is being blocked