Hi folks! This one is somehwat complicated, so I’ll try to summarize it as easily as possible:
I have a client who recently moved their web hosting from a local IIS server to an commercial external host. However, the new host has repeatedly shut off access from the client site because their server is detecting “port scans” from the client’s IP address. As part of the troubleshooting process, I’ve been running Wireshark on the servers, and the server that runs OpenFire ("xmpp-server’) is repeatedly trying to contact the new webhost on port 5269.
My question is… why is OpenFire trying to do this?
As a bit of background: I set up this client with a COMPANYNAME.LOCAL AD domain, and a forward lookup zone for COMPANYNAME.COM, so that internal users could use the same addresses whether internal or external. The users at this site are not very technical, so I was afraid they wouldn’t understand using SBSSERVER.LOCAL to access the public site internally and WWW.COMPANYNAME.COM to access it externally. I also set up an A record for CHAT.COMPANYNAME.COM so that they’d have one address to connect to the OpenFire server. However, when moving the public website to an external host, I deleted the forward lookup zone on the SBS server, so this should no longer be an issue.
Also, on April 11, 2011 I had to add COMPANYNAME.COM as system property xmpp.fqdn to get OpenFire to work with non-Spark clients like Pidgin. However, that bug was fixed in 2.7.0 and so I deleted xmpp.fqdn on August 10, 2011. So I don’t even know how OpenFire “knows” about the external site.
BTW, I will upgrade this client to 3.8.1 after EOB today, if that helps.
To clarify, this client has one server running SBS 2003 (which hosted their public website until March 15). They have another server running Windows Server 2003 which runs their POS system and OpenFire.
Do you need S2S enabled? If not, just turn it off and problem is solved.
Did you capture DNS lookups also? Would be interesting to see what DNS lookups the system is performing prior to making the TCP connection to this system.
What is your xmpp.domain set to?
Actually, I did disable that just before I posted this. Somehow I totally missed the connection between s2s and port 5269.
I’d still like to know why OpenFire was actively trying to connect to the external webserver, though. To me there’s a big difference between “remote servers can exchange packets with this server” and “this server is actively going to try to connect to an external IP”. Ya know what I mean?
And how did OpenFire know to connect to that particular IP, anyway? As you suggested, I’d need to look at the DNS data. I do have a new DNS record for CHAT.COMPANYNAME.COM (and the external NS servers are with the new webhost)… but why OpenFire would even try to connect in the first place is a mystery to me.
Also, xmpp.domain is set to the local server name. Let’s just call it SERVER. Perhaps I should change it to COMPANYNAME.LOCAL (the AD domain?)
FTR, I’m not using AD integration… they only have 10 users and I don’t know much about LDAP, so when I set it up in 2007 it was easier to keep it all in OpenFire.
xmpp.domain should match whatever domain the users are logging in with. If, for example, xmpp.domain is whatever.com, but users are using something.com, it’s not unreasonable it may do S2S to communicate with a something.com user since it doesn’t know it is local to it.