Bind to specific IP

Is there anyway to bind Wildfire to a specific IP? I have an Asterisk box and I want to install Wildfire on it. But whenever I use the “dial” function of Spark, the client application quits and I get this in the log file.

2005.12.31 11:05:05 Could not route packet

If I setup a separate Wildefire server on a different machine, it works fine. So I am guessing if I can bind Asterisk to 1 ip and Wildfire to another, it should work just fine on a single machine.

Thanks,

Greg

I know how to bind the client ports, however I’'d like to know how to bind the admin console as well as the server ports / component ports.

I have tried with adminConsole.interface, it did not work.

/etc/hosts has the server name pointed to the right name. Any ideas would be helpful. I have a /24 of IPs on the box, which really doesn’'t help having that bound to every one of them.

BTW to bind the client sockets:

xmpp.socket.plain.interface

xmpp.socket.ssl.interface

This doesn’'t work for wildfire 2.4.3 anymore !!!

Hey guys,

As of Wildfire 2.4.3 there is only one property used for binding to one IP address. The same property is used for client-2-server (plain/TLS/SSL), server-2-server, external component and the admin console.

You should now define the network.interface[/b] property in the wildfire.xml file and then restart the server.

Regards,

– Gato

I just created the following url=http://www.jivesoftware.org/community/entry!default.jspa?externalID=503KB document[/url] that explains the steps to follow.

Hope that helps.

Edited: The URL is so long that forums is breaking it. Just remove the white space. The link is http://www.jivesoftware.org/community/entry!default.jspa?externalID=503]KB document.

– Gato

Message was edited by:

dombiak_gaston

Hi Gato,

may I ask who had the idea for such a change?

Some admins do not want to bind the admin console to the same IP address as the XMPP server, now they must use a firewall to restrict access to it. Or run everything on 127.0.0.1 and use a TCP-proxy for port 5222 to make it available to a public interface.

Is it possible to seperate the settings? Maybe using settings like network.interface.adminconsole or network.interface.s2s which would overwrite the global network.interface setting?

LG

LG,

The idea was mine. It was getting very complex to setup Wildfire in a multi-homed environment. Having to remember five different properties to set is just not good for 99% of users.

In general, I think a firewall is the best place to handle restricting access to services since it’'s a unified place to control access to your entire network. However, we definitely support having useful security tools for Wildfire. So, the question – is it more helpful to bind to a certain interface for the admin console or to restrict access to the admin console to a set number of IP addresses? Based on how we usually setup our firewall, I would say the latter, but am interested to hear what others think. We could support both options, but also want to keep setup simple.

Regards,

Matt

I’‘d say that binding the admin interface to a specific IP address would be useful, and shouldn’'t be THAT hard to allow in addition to the current (new) way of doing things. In other words, network.interface should be the one-stop-shopping way to bind everything to a single IP address, but if network.adminInterface (or some such property) is defined, then just the admin interface would bind to that one instead.

Does that make sense?

Gato:

A suggestion for the KB article:

might be a little easier to follow than saying ‘‘network.interface’’ and ‘‘mylocaladdress’’.

Hey Max,

Thanks for the suggestion. The KB document has been updated. I don’'t know why but the where not being correctly rendered. Let me know how it looks now.

Regards,

– Gato

Gato:

Looks good I figure that the bracket tags weren’‘t being rendered because they are code and need to be preceeded by a code[/b] or a pre[/b] tag. I tried to add a comment and point out that the network tag should be separate from the adminConsole one, but despite specifying the pre and code tags, it didn’'t render properly on posting, which I figured was due to an admin restriction on posting code snippets.

Anyways… thanks for fixing this.

–Maxx

In general, I think a firewall is the best place to

handle restricting access to services since it’'s a

unified place to control access to your entire

network.

Agreed. A packetfilter/firewall should be used anywayl.

However, we definitely support having useful

security tools for Wildfire. So, the question – is

it more helpful to bind to a certain interface for

the admin console or to restrict access to the admin

console to a set number of IP addresses?

I’‘d either do the first or both. I think it’'s far more easy to bind the admin console to 127.0.0.x and proxy requests (depeding on your firewall rules, the remote ip, the time or phase of the moon) there than adding IPs to a config.

The current way to do that (binding everything to lo and NATing the XMPP things) seems to be far more complex and harder to handle.

We could support both options, but also want to keep

setup simple.

You stated that the current solution is good for 99% of the user. Fine - stick with this default but add the options for the 1% (three guys in this thread already =) ) that need it. Shouldn’'t make it harder for the “just works out of the box” user?

Just my humble opinion,

Ben