Hi, just a footnote on this thread. If still open / relevant?
- you have an on-prem 3cx instance ? (ie, in office, on your hardware, behind a firewall / cisco presumably / to reach the internet?)
- your have a public FQDN like "mycompany.3cx.com" for your instance
- you need this to resolve internally on DNS such that a PC in the LAN > ping to mycompany.3cx.com > returns the LAN IP of the device (192.168.0.99 or something) ? (ie, PC inside LAN uses your local Cisco firewall for DNS server? or maybe a windows domain / AD controller/ more drama? or maybe not? )
- and in same vein you want external people (ie, person at home office) when they ping to mycompany.3cx.com > to get the public IP address of your office where cisco firewall exists, and presumably has inbound port forward rules or something, to allow external world client devices to talk to the 3cx instance cleanly?
- or maybe something here is not correct? (if so please clarify?)
broadly speaking, for what it is worth. Putting your 3cx instance on a public-hosted public IP VM will be much easier to manage than keeping the 3cx instance inside your LAN network behind a (cisco or other) firewall. But maybe you already know that. or maybe not?
anyhow. In theory the split DNS / hairpin behaviour - can be at least partially debugged via a bit of testing from (PC inside office vs PC outside office) and review of what responses you are getting.
or in theory you can make that drama go away with a simpler 3cx server setup.
I am happy to try to help a bit via forum post/reply/discussion if this is helpful. But it may be limited what we can do here.
Tim
