Hello!
There is a DUAL homed Wildfire 2.5.0 running in test mode over here. One interface is on internal 192.168.x.y and the other is on the OUTSIDE (=official IP)
The machine is NOT running as a router but can be accessed from both sides for VOIP and Jabbering.
At the moment I opened for Wildfire TCP ports 5222, 5223, 5269
What about this mysterious port 7777?? Any other ports needed? Do I need all of the above?
thanks for thinking
starry
port 7777 is the file transfer proxy you will want that open if you want to facilitate easier file transfers over jabber.
Alex
Thanks alot!
Hello!
It is me again.
As I wrote in my first post the server 2.5.0 is dual home and File Transfer Proxy is enabled.
I opened port TCP 7777 (is this right or do I have to open UDP??) but the filetransfer does not yet work from the innner network to an outside spark client, who is behind a DSL-NAT router.
The remote client is 1.1.2.5 the local inhouse is 1.1.3
Are there any known issues?
thanks for thinking!
Starry
Hi starry,
Do I need all of the above?
The other ports are:
5222: client-to-server.
5223: client-to-server with ssl (encrypted).
5269: server-to-server.
If you want people from OUTSIDE the firewall to be able to connect from their client to your server you must open port 5222 (and/or 5223).
If you want people connected to your server to be able to chat with people from ANOTHER server (or use gateways such as ICQ or MSN) you must open port 5269.
/John
Hello!
The other ports are:
- 5222: client-to-server.
- 5223: client-to-server with ssl (encrypted).
- 5269: server-to-server.
Checked OK here as well as the TCP-7777 for the file transfer proxy.
I’'ll keep on testing and let you know!
Thanks!
Starry
Hey Starry,
It should work with just TCP but you do have to set the property xmpp.proxy.externalip on your server with the domain name or IP where your proxy service can be reached. I may default this in the future to the service name of your server in the future but currently it discovers the internal IP which isn’'t very useful for most purposes
Thanks,
Alex
Hello!
thanks for the tip!
As I did not find it in the Web Gui I manually added it on the Server Properties sheet and restarted the server. I hope that this was what you suggested.
Bye
Starry
Hey Starry,
Yea that is exactly what needed to be done… though an approriate field needs to be added to the web gui.
Thanks,
Alex
I followed all the instructions here, open up port 7777, added property xmpp.proxy.externalip, set the value to 127.0.0.1, restatred Wildfire. Clients inside the firewall and outside the firewall will be able to connect and trying to transfer file, and the one receiving file inside the firewall was able to see the file name, size. But then it stucks forever. Sure the 5222 port is open too. Wildfire is 2.50 and Client is 1.13. What gives?
127.0.0.1 This is the loopback interface. This means that the file transfer will connect back onto itself. In this field you will want to specify a value to which external clients can access your server on port 7777.
Hope that helps,
Alex
So let’'s say the wildfire is on 192.168.1.60 and firewall router is 192.168.1.1 and someone on the internet is 88.88.88.xx then what will be value here? I will have 192.168.1.1 TCP port 7777 open and forward to 192.168.1.60. Thanks a lot!
Are you sure the external IP of your router is 192.168.1.1? This doesn’‘t look like an external IP address, its more likely the address of your firewall/router on your internal network, if you have a website configuration for your router you should be able to see its external IP address somewhere in there. You’'ll then want to NAT requests to your firewall on port 7777 to 192.168.1.60 on your internal network.
Cheers,
Alex
Oops! Yeah, I think I stated it wrong. Yes, I put the external IP on the firewall/router in the wildefire system property. Then forward the port 7777 to 192.168.1.60. But still stucks. Does the one on the internet needs to configure anything? Thanks again, Alex!
I may be wrong, but I’‘m pretty sure when they refer to your “external IP address”, they are referring to your WAN IP. 192.168.1.1 is a router IP, because that’'s my router IP as well, and then your LAN IP would be 192.168.1.60 (Mine is 192.168.1.20), and then for people outside your network to access you would need to specify your WAN IP, which, mine is 24.26.45.2, you can check yours at http://www.ipchicken.com
As I said in the beginning, I may be wrong, but I’'m pretty sure your “external IP” would be your WAN IP.
Regards,
Ken
Just to clairify…
Can you set xmpp.proxy.externalip to a domain (example jabber.xyz.com) instead of an IP?
Thanks!
xmpp.proxy.externalip can be set to a domain name, yes.
Alex
etherboy:
Which client are you using? Is there a way to see your log files? Do you see any errors in them or anything along those lines?
Thanks,
Alex
Hi Alex:
Thanks for your help! Here is the situation.
At first I tried to transfer one file and not successful, so I cancel and try again with another file “sample.jpg”
The remote client which logged in as “admin” is behind a router with a computer IP 192.168.1.10 and is the one sending files, which I did not make any changes on the router. “etsai” is the one receving files on the same network with wildfire. That’'s why I asked if I have to configure anything for remote user client.
Internal Spark & remote Spark both are 1.1.3. Wildfire is 2.50.
Log file attached.
Regards,
etherboy
All Packets
Raw Sent Packets
Raw Received Packets
Hey:
It appears as though wildfire is still providing its proxy ip as the internal IP: 192.168.1.60. Make sure you have the correct jive property set on wildfire: xmpp.proxy.externalip. This value should be set to the external address, or WAN address of your router. After this is done, wildfire does need a restart so, do so, when it starts again look again in the log file for the address if it doesn’'t work:
/code
it is the address provided next to the jid proxy.apps01, and make sure if it is the correct one.
It should be failing over to IBB, I can see the sender offering but I think I know why it isn’‘t. Looks like etsai successfully connects to the proxy, and then is stuck waiting for admin to connect, and I think this is a case that isn’'t currently accounted for so I am going to look into fixing that.
Thanks,
Alex