Hi, quick note to followup in this thread, in case it is helpful. The 3cx SBC can happily run as a VM on proxmox - I have a bunch of sites doing exactly this - Proxmox physical host inside the LAN office. SBC is installed as a (KVM Bare metal virtual machine - is most simple) - use the 3cx ISO installer in proxmox and choose the "SBC Install" config path. Once you do this, later in install it will demand info from you to proceed / to identify the public FQDN of your 3cx instance. There are also AUTH_TOKEN you must provide to validate the link from your 3cx to this SBC.
once you do this cleanly, your SBC will be alive, make sure it remains operational at all times lest you interrupt phone connectivity.
After that, the SBC is basically acting as a PROXY for all the VOIP traffic. This means both
(a) PNP Stuff related to phone auto-provision and discovery
(b) Voip phone call traffic / inbound outbound etc.
note for greatest simplicity, you will want to give an IP that does not change to your SBC inside your LAN at time of deployment. This could be a Static-assigned DHCP via MAC address mapping in your DHCP server, or a static IP like 192.168.0.222 or whatever it is for your environment which is free IP / works etc. But ideally don't change the SBC VM IP address. Makes life simpler so phones always know how to reach 3cx and vice-versa.
Then the SBC will proxy all the traffic phones<>3cx. Life is good. No drama with your office firewall and opening ports and NAT and .. firewall rules and on and on and on.
Towards your original question, 'how come it worked of for the first phone' - I believe the first time I deployed 3cx and didn't understand yet how SBC was important. I also deployed bare phone handset, and it worked. Then I added second, and third, and they kind-of-worked except - calls were weird, flakey, routing was confusing, I was having a bad day. It turns out that if your handset is not a modern type that does the SBC-integration-internally / self-traffic-tunnel for you -- then you really do want to have an SBC. Because firewall port rules and default behaviour otherwise make for a long day of 'arrgh why did this sort of work but now it does not?". VOIP traffic protocls with legacy hardware are ~complicated in terms of firewall traversal, port open/forward behaviour, traffic for data-voice vs session-init etc etc. All this to say. SBC is your friend. So much easier once it is lit up.
Happy testing!
Tim