RE: [sipxcom-users] sipXcom 25.01 Configuration Issue

[sipXcom Newbie]

OnRelay Support, Thanks for the fast reply -- appreciated.

I can but try it (--reset-all) then do a deep directory grep for the private address under /etc and /var to check for stickiness.

TBH, you do say it works with a single interface -- so I had been warned. (Perhaps understandably, I was trying not to expose ssh etc. to the public interface while, telling sipXcom only of the existence of the public address).

Is it possible to hide the existence of the private interface while configuring sipXcom, or is it that sipXcom should simply not be configured while two interfaces are active?

If sipxecs-setup should never be run while two interfaces are active, will it tolerate being configured with a single public interface being active, then, after configuration, a second, private interface varied online?

Thanks.


----- Original Message -----
Date: Tue, 5 May 2026 15:49:17 +0200
From: Support <sup...@onrelay.net>
To: sipXcom Newbie <sipxcom-text...@tel.co.uk>
Cc: sipxco...@googlegroups.com
Subject: Re: [sipxcom-users] sipXcon 25.01 Configuration Issue


Hello,

Yes, you may attempt to run the sipxecs-setup command with the --reset-all option to clear all previous settings.

Still beware some of those original settings can still be quite sticky in both generated config files and database tables, so the safest approach is likely to reinstall and run sipxecs-setup with the corrected parameters.
_______________________

OnRelay Support

US: +1 415 523 6400
AU: +61 285 038 070
UK: +44 208 629 1460
NO: +47 21 93 72 27

sup...@onrelay.net <mailto://sup...@onrelay.net> | www.onrelay.com <http://www.onrelay.com/>


> On May 5, 2026, at 2:05 PM, sipXcom Newbie
> <sipxcom-text...@tel.co.uk> wrote:
>
> ## sipXcom 25.01 Configuration Issue - Server Remains Configured with
> Internal Address
>
> #### 1. Expected Behaviour
> On a physical server with the lowest NIC configured with a private
> address and the next highest NIC configured with a public address and
> with `sipxecs-setup` initially run giving the private address as the
> server IP, then `sipxecs-setup` re-run correcting the IP address to be
> the public address followed by `service sipxconfig restart`, that the
> changed-to-public address reflect in the single server configured as
> "Primary" on the /sipxconfig/admin/commserver/LocationsPage.html page.
>
> ### 2. Actual Behaviour
> On a physical server with the lowest NIC configured with a private
> address and the next highest NIC configured with a public address and
> with `sipxecs-setup` initially run giving the private address as the
> server IP, then `sipxecs-setup` re-run correcting the IP address to be
> the public address followed by `service sipxconfig restart`, the IP
> address against the single server configured as "Primary" on the
> /sipxconfig/admin/commserver/LocationsPage.html page remains unchanged
> (as the private address).
>
> Similarly:
>
> /etc/sipxpbx/domain-config still shows the private address against
>
> `SIP_DOMAIN_ALIASES`
>
> and /etc/sipxpbx/sipxsupervisor-allowed-addrs.ini still only contains
> private addresses.
>
> The UI does not permit the single server configured as "Primary" to be
> deleted or edited.
>
> Short of reinstalling 25.01, is there a way to correct the server from
> not listening on the right address or a way to "factory reset" 25.01?
>
> Thanks in advance.
>
> --
> You received this message because you are subscribed to the Google
> Groups "sipxcom-users" group. To unsubscribe from this group and stop
> receiving emails from it, send an email to
> sipxcom-user...@googlegroups.com. To view this discussion
> visit
> https://groups.google.com/d/msgid/sipxcom-users/20260505130539.48384105%40tel.co.uk.

[Support]

Thanks!

You can also grep the contents of PostgreSQL with: pg_dump -U postgres -a sipxconfig | grep <pattern>

It is doubtful trying to hide the internal SSH enabled interface from sipXecs is a workable approach, since SSH is used for internal intra-service connectivity as well. You will note from logs there are a few SSH keys etc that are generated during setup.

It is probably better to connect sipX to an IPSec VPN GW and allow ‘public' SSH only via that route there

You should similarly be careful exposing SIP ports 5060 / 5061 to the general public, since e.g. some older IP phone models are hackable.

[sipXcom Newbie]

Great and fast support OnRelay!

--reset-all worked like a charm pretty much. (I re-configured while the private interface was down).

One nit, the old, private, address still populated as the primary external DNS server on the /sipxconfig/dns/EditDns,form.sdirect and /etc/resolv.conf listed itself as the single nameserver. After populating additional external and unmanaged DNS servers in that page (and applied the changes, obviously), /etc/resolv.conf was still runt. Overwriting /etc/resolv.conf with a copy with three nameservers won't fix it since within a few seconds it overwrites it again with the runt one. So I can correct it at source, where is it getting the nameservers it writes to resolv.conf please? as it's out of sync with what is showing in /sipxconfig/dns/EditDns,form.sdirect

`pg_dump -U postgres -a sipxconfig | grep <private network>`

pleasingly only returned private addresses under `sys/unmanaged_servers/unmanaged_0` and `1`.

Public ssh is locked-down so not overly concerned there. (Does seem a little unconventional to have to locally access servers using their public IP).

It's not being evaluated as a local PBX -- *it's* SIP ports do need to be publicly-exposed. The SIP ports of internal phones are not exposed over any public IP. External phones are on natted public IPs but configured to accept SIP messages only from SIP registrars they register to (otherwise it would be an open invitation to sipvicious script kiddies). Let me know if sipXcom is unsuited to either use case.

Kindest

[Support]

Hello,

Comments below:

DNS:

The external DNS servers configured at the EditDns form are replicated to /var/sipxdata/cfdata/1/named.cfdat and onwards to /etc/named.conf. These update OK on 25.01.

The local IP DNS server you see is in /etc/resolv.conf is just your local IP DNS server.  If the DNS service is enabled a sipX DNS server runs locally. Addresses that cannot be resolved locally are forwarded to the above mentioned external DNS servers.

It is possible to edit the FC engine config files that auto-generate system config files, such as /src/sipxecs/sipXconfig/etc/sipxdns.cf, but would advise against it. 

SSH:

sipX is designed to run in distributed clusters. And the master server e.g. uses SSH for remote server control. 

SIP:

NATing both for SIP trunks and SIP extensions work really well, and if you enable SIP / TLS and SRTP the invites / registrations etc are also secure.

It is also possible to expose 5060 / 5061 to 0.0.0.0/0. The same goes for the default SIP trunk ports 5080 and 5081, but it has to be done with great care, irrespective of SIP engine.

You e.g. have to consider in particular the following:

• Denial of service attacks. You will have continuous bot attempts to register and invite, and it is strongly recommended to have a firewall mechanism to monitor and selectively block high volume traffic to these ports irrespective of whether you use the sipX built in fail2ban service or not.

• Physical / soft phone hacking. The physical phone or softphone can be hacked while residing on a public or private network, i.e. via its web config interface. The hacker may be able to get the SIP uid/password combination this way, and register with a SIP spoof attack from somewhere else. Before you know it you are the termination point of an illegit router of international calls.

We have dealt with these issues at OnRelay for a long time, and it has been years since we had a breach. We found at the end of the day strong firewall rules combined with customer self-configurable IP whitelisting work robustly and with the least amount of hassle overall, although we realize it may not always be sufficiently flexible. It factors that most of our regular users use our mobile apps and cell network voice connectivity routed via protected SIP trunk interfaces.

It is also worth mentioning in this context using secure SIP over TLS has a great benefit that it removes a major remote SIP NAT hassle with disabling SIP ALG in routers, since ALGs cannot modify encrypted SIP packets.