Client Connections Refused through Firewall

Openfire Openfire Support
1

Hello!

We’‘ve had Wildfire running very successfully in our organization for almost a year now, and we’‘ve loved it! We have S2S jabber working with google talk, and have recently decided that we’'d like to further open our jabber server up to client connections outside of our firewall – so that remote users can access the chat without a vpn connection.

We already had port 5269 (TCP) open on our firewall to our wildfire server, and also have the necessary NAT setup. This has worked flawlessly.

We added 5222 (TCP) and 5223 (TCP) to the existing firewall access rules and the NAT table.

We’'re unable to connect from outside the firewall.

If we attempt to “telnet public.server.ip.address 5222” or “telnet public.server.ip.address 5223” our connection is refused… “connect to address public.server.ip.address: Connection refused”, “Unable to connect to remote host”.

The same telnet to port 5269 works flawlessly, allowing us to type some xml to the server and getting a response.

The above telnet commands to 5222 and 5223 do work from within the LAN (replacing public.server.ip.address with private.server.ip.address).

Any thoughts?

Thanks!

We are running Wildfire 3.1.1 on Windows Server 2003 behind a SonicWall 3060 Enhanced OS firewall

Message was edited by: colby

Added Wildfire version and platform

2

If I turn on debug logging, I see the following:

2006.12.20 22:19:23 Connect Socket[addr=/[my.internal.client.ip],port=56121,localport=5222]

2006.12.20 22:19:26 Connection closed before session established

Socket[addr=/[my.internal.client.ip],port=56121,localport=5222]

Which is only my telnet attempt from within the network. My telnet attempts from outside the network do not appear in the debug log.

3

bump.

4

I’‘m not exactly familar with the SonicWall 3060 Enhanced OS firewall, but most routers/firewalls need to have the external IP maped to the internal. If your firewall has these configurations in them “port forwarding” and “Port triggering (for applications such as servers)” and these were not part of the NAT configs you described, I’'d suggest setting these up.

Message was edited by: linksys

5

Hi Linksys, thanks for writing. We’‘ve already taken care of this… which is how we’'re similarly able to have S2S communications with Google Talk, as well as being able to telnet into port 5269 from outside the network.

6

FWIW our connection is no longer refused… however it doesn’‘t matter much as the current status hasn’'t brought us closer to a resolution!

telnet public.ip.add.ress 5223

Connecting To public.ip.add.ress…Could not open connection to the host,

on port 5223: Connect failed

This is the same for 5222 or 5223.

7

OK – actually it seems that nothing has changed, it’‘s simply a different response from Windows’’ Telnet and Mac OS X’’ telnet.

Still can’'t connect remotely from outsite the firewall (using a jabber client, or telnet)

Anyone?

8

Hey colby,

Which is the domain or public IP address of your server? I’'m guessing that public.ip.add.ress is just an example. As long as telnet is failing then no client will be able to connect. If you are going to use a domain then you will have to add some DNS SRV entries to your DNS server.

Regards,

– Gato

9

We already have SRV records in place on our public DNS. I also do realize that until I’‘m able to telnet, clients will be unable to connect… which is why I’'ve been using my ability to telnet in as the basis for troubleshooting this issue.

The ip address that I’‘ve been using in the above diagnostics is the wan ip address that is nat’‘d through to our wildfire server. I also demonstrated above that this does work, by showing that i’'m able to telnet into the S2S port and get a response… however my telnet connections to the client ports fail.

We do have S2S functioning perfectly with Google Talk. We are operating on a S2S whitelist, only permitting S2S connections with gmail.com’'s server.

We’'re still unable to connect to our wildfire server, with a client, from outside our firewall.

Any replies are greatly appreciated.

10

bump.

11

Is anyone able to use Wildfire 3.1.1 in this manner?

12

Hi,

as long as you can’'t connect to Wildfire you need to tweak your firewall. Can you there enable logging for IP:5222 to see if the SYN or the REPLY packets get dropped? Or can you see packets pass in your firewall log?

As s2s works I don’'t think that you have a routing problem.

LG

13

You prompted me to double check that, and i resolved it.

I think I may have actually uncovered a bug in the SonicWall OS… I deleted the service and recreated and it all started to work. I noticed that if I change an existing service, even simply renaming it, the firewall no longer observes the setting.

Fixed! THANK YOU!

14

Interesting. I am having the same issue with a SonicWall. Which part did you have to delete and re-create?

15

SonicWall has confirmed the issue I discovered. The quick fix? Restart the sonicwall and the changed service object/group will be recognized. If a reboot is not possible, recreate the service object/group (rather than editing an existing)

… See full details below…

DTS #47619 “Access Rules w/ Service Groups stop passing traffic if member service is edited” was created for this issue. Please read details below.

Steps to Reproduce

Comment #1 from Sonicwall on 2007-02-14 16:23:35.134239 -

Create inbound config w/ rules and NAT policies using the public server wizard,

or manually, using a service group.

Confirm inbound traffic works using that config.

edit the name or port definition on one of the services in the group

change the server on the internal network to use the newly-edited port number

confirm that the server is answering that port as seen from a testing client on

the inside

try reaching the server on its new port from outside, through the firewall ; it

will fail.

Look at the logs and see the dropped TCP entry from your attempt.

Job Workaround

Comment #1 from SonicWall on 2007-02-14 16:23:35.134239 -

restart firewall or re-create the rule.

Job Comments

Comment #1 from SonicWall on 2007-02-14 16:23:35.134239 -

Description of problem:

SonicOS Enhanced versions 3.2.0.0 through 3.2.4.0 have a problem in which an

access rule stops working if:

a) it uses a Service Group

b) one of the member services is edited in any way

I have verified this using my TZ170SPW. I have a webserver on the LAN and I

have a service group which contains the web port 8000 and a few mail protocols

like SMTP and POP3. If I edit the service web port 8000 to 8001 instead, and

then change the webserver to answer on that port, traffic from the WAN to the

webserver on the LAN will fail and will be logged as dropped TCP (with no rule

citation).

If I create a new rule using the service group or the individual web port 8001,

it works fine. A restart will also restore connectivity. I suspect that other

types of changes to the service group, such as removing or adding member

services, might have a similar effect. More testing is needed.

Customer wrote in SR:

Bug Report: If I have a Firewall rule setup utilizing a defined service,

and then change any aspect of that service - such as a port

range or even service name - the rule ceases to function.

Example:

Access Rule:

WAN > LAN

Source: Any

Destination: All WAN IP

Service: SRWEB01 Services

Action: Allow

Users: All

SRWEB01 Services is a service group containing:

Jabber S2S

Jabber Client

Jabber S2S is a service defined as:

TCP 5269 to 5269

Jabber Client is a service defined as:

TCP 5222 to 5223

This works if I build the following from scratch, however if

“Jabber Client” is initially 5222 to 5222 and i change it to

5222 to 5223, I am unable to use either 5222 or 5223 (the

entire “Jabber Client” service). The same occurs if the

service is initially named “Test” and I rename it to "Jabber

Client", even if the ports do not change)

Version-Release number of selected component (if applicable):

3.2.x.x Enhanced on any platform

How reproducible:

100%

Actual results:

traffic stops after real-time edit of service used in a rule

Expected results:

traffic attempted against a rule is re-evaluated in real time, after real-time

edit of service used in a rule

Additional info:

I don’‘t see this behavior in 4.0.0.0_21e on Pro4060 and I suspect it’'s not in

3.5.0.0 Enhanced either. I’'ll update this case w/ news on that front.

16

Restarting the Firewall seemed to work fine. Thanks!