Solved 3CX in DMZ and SBC behind 2nd FW: Can't connect via FQDN

[MucCX]

So I have installed 3CX successfully in a DMZ and routed all the necessary ports from the external FW to 3CX. 3CX's FW test is sucessful. I have provisioned an SBC under SIP Trunks.

Currently, I am trying to set up an SBC in a dedicated VM behind the internal FW (the FW does not block any outgoing traffic), using the Provisioning URL and the Authentication KEY ID provided by 3CX. But I can't get the SBC to connect: When I supply my 3CX FQDN, SBC tells me that it unable to reach the server.

However, this does not appear to be a DNS problem, because I can ping my 3CX FQDN.

So what is this?

One thing to note: When I try to browse to my 3CX FQDN from within the inner FW (where the SBS is located), Chrome tells me that [my 3CX FQDN] "normally uses encryption to protect your information. When Chromium tried to connect to [my 3CX FQDN] this time, the website sent back unusual and incorrect credentials. This may happen when an attacker is trying to pretend to be [my 3CX FQDN] or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Chromium stopped the connection before any data was exchanged.

You cannot visit [my 3CX FQDN] right now because the website uses HSTS. Network errors and attacks are usually temporary, so this page will probably work later."

However, if I browse to my 3CX FQDN from outside the network, I see the management console.

Any help greatly appreciated.

 

[cobaltit]

Sounds like you've already identified the issue and it's your internal firewall. Once you resolve that you should be good to go.

 

[MucCX]

Yes, the FW was the problem - it wanted to protect from a potential DNS rebinding attack.

The solution was to "short circuit" the name resolution for my 3CX FQDN on my internal network. I added my 3CX FQDN to the list of hosts DNS queries for which are answered locally by the internal FW instead of through the internet.