Right, what I was saying was that you shouldn’t need it opened incoming, just outgoing. So long as the server running the IM gateway plugin can poke through to the outside world through port 443 and 1863, in theory, you should be good to go.
I made a mistake (this won’t change the result but let’s be precise)
Here is the correct ports opened in my corp. FW:
1863
5222
5223
5269
7777 (now opened)
File transfer now works perfectly (though I’ve got the same issue than http://www.igniterealtime.org/community/message/121660
but which won’t forbid me from using it)
I think I’ll close 1863 though as it is not needed (outgoing traffic IS allowed !) and according to mtstravel, this is not needed (his config do not include those ports as open and yet it indeed works).
I will wait for your package (if you can give me a brief manner to install it instead the previous one, it would be very nice ! Do I just need to overwrite the previous one one the filesystem and restart openfire ?)
Thanks in advance,
cgravier
So is your squid server using transparent proxy, a pac file, or manual config on each browser?
There is a way to configure squid servers to automatically deny traffic to certain transports (http://www.codingmentor.com/forum/block-messenger-aol-yahoo-msn-services-through -squid-t-147.html).
I have 3478 & 3478 open because my server is behind all our routers and firewalls and has a 10.x.x.x NAT address. Those ports are supposed to be for that purpose. Oour server is being translated via the router to a real world static IP address.
Ok, attached is a version that will spew debug logs during the auth process. Ignore the “Request property is null” message btw, that was something I thought would work that I was wrong about. The new messages should show up in your debug logs and will be tagged with MSNDEBUG. Lets see how this goes. =D
gateway.jar (1179896 Bytes)
squid is used as a non transparent proxy, each browser need to set the proxy adress and there’s no way to modify it (I don’t have the control over it and this is a wish by the admins anyway).
Regarding the URL for blocking IM using squid, you may be right.
I performed some tests:
- Tried to telnet a 1863 msn server:
telnet messenger.hotmail.com 1863
Trying 65.54.239.80…
Connected to dp.msnmessenger.akadns.net.
Escape character is ‘^]’.
Seems OK.
-
I went to my deskmate windows box, and tried to installed msn. After I realized he already installed that instead of a jabber client, and after I kicked his as , i checked that it was working.
-
This is also working using gaim and my msn account on my linux box
Haha we’re going closer…
Here is the log
2007.09.05 16:29:23 MSNDEBUG: We are doing auth, opening a thread to handle it
2007.09.05 16:29:23 MSN: Session messageReceived for xxxxxxx@yahoo.fr : USR 3 TWN S lc=1033,id=507,tw=40,ru=http%3A%2F%2Fmessenger%2Emsn%2Ecom,ct=1189001841,kpp=1, kv=9,ver=2.1.6000.1,rn=*ZPQvkAE,tpf=54145b516b39469e9fb7a9a27a70e656
2007.09.05 16:29:23 MSNDEBUG: Time to request the login ticket for auth
2007.09.05 16:29:23 MSNDEBUG: Retrieving passport url
2007.09.05 16:29:23 MSNDEBUG: Lets ask the nexus what passport url to use
=>>>>>
2007.09.05 16:30:24 session 4 closed
2007.09.05 16:30:24 MSN: Session closed for xxxxxxx
@yahoo.fr
I can’t say much here, but you may be able to track the line that cause the problem ?
cgravier
Eww. Ok, well, that means the server can not communicate with https://nexus.passport.com/rdr/pprdr.asp
Why it can’t do that I’m not clear on, but that’s what the root of the problem is.
So… lets try something. Try this version.
gateway.jar (1179903 Bytes)
Different log output here:
edit: hardly readable paste because word formatted
more readable format:
2007.09.05 16:51:06 MSNDEBUG: We are doing auth, opening a thread to handle it
2007.09.05 16:51:06 MSN: Session messageReceived for xxxxx@yahoo.fr : USR 3 TWN S lc=1033,id=507,tw=40,ru=http%3A%2F%2Fmessenger%2Emsn%2Ecom,ct=1189003144,kpp=1, kv=9,ver=2.1.6000.1,rn=OkqPX7HW,tpf=646496e95d688ae158aa2fd68e12407b
2007.09.05 16:51:06 MSNDEBUG: Time to request the login ticket for auth
2007.09.05 16:51:06 MSNDEBUG: Retrieving passport url
2007.09.05 16:51:06 MSNDEBUG: Retrieving the login ticket from url https://login.live.com/login2.srf and passport xxxxx@yahoo.fr
2007.09.05 16:51:06 MSNDEBUG: Setting request property
2007.09.05 16:51:06 MSNDEBUG: Request property is null
2007.09.05 16:52:06 session 2 closed
2007.09.05 16:52:06 MSN: Session closed for xxxxx@yahoo.fr
Well crap, that means the direct url failed as well. So the gist of it is, the server does not appear to be capable of making outgoing port 443 requests. Why I can not tell you. I do know that my networking peeps where I work will sometimes be a little too overprotective and if I ask for special rules for a server they’ll lock down -everything- else for that server that I didn’t explicitly ask for. So you might want to check if there is a restriction on outgoing port 443 for that specific server/machine that’s running openfire.
An easy way to quick test if port 443 works, btw, is to set your MSN connect host to login.live.com and connect port to 443 and just see if the connection test succeeds. (it won’t work to leave the setting like that, but it’s worth a test)
You may want to open UDP for those ports as well. It should not be needed, but I did do it for my server and it is working swimmingly.
Did you mean my msn gateway ?
If yes, the test did not give failed or success in admin console, and in debug log I receive:
2007.09.05 17:05:44 EOF
2007.09.05 17:05:44 Exec[0]: ConnectionTester.testConnection()
2007.09.05 17:05:44 --Object created, not stored. Call params (string:login.live.com, string:443) id=5243_1189004052216. Using (XHR,POST)
2007.09.05 17:05:58 Returning: id[6396_1189003877320] assign[s0] xhr[true]
2007.09.05 17:05:58 var s0=false;
DWREngine._handleResponse(‘6396_1189003877320’, s0);
2007.09.05 17:06:34 Exec[0]: ConnectionTester.pingSession()
2007.09.05 17:06:34 --Object created, not stored. Call params () id=9835_1189004102340. Using (XHR,POST)
2007.09.05 17:06:34 Returning: id[9835_1189004102340] assign[s0] xhr[true]
2007.09.05 17:06:34 var s0=null;
DWREngine._handleResponse(‘9835_1189004102340’, s0);
I don’t know what s0 variable stands for, but when using messenger.hotmail.com:443, it says test successfull and s0 is set to true in debug log.
I also tried to directly telnet the server:
telnet login.live.com 443
Trying 65.54.183.203…
But I can’t connect from my lan !
I asked to a mate who is at home using abasic dsl connection, and the telnet also fails… (he is not using the proxy… or maybe is it a NAT problem at his hme but it is an outgoing connection to 443, so NAT is not required in my opinion.)
Well, I think I didn’t understand how to test the 443 port 
Can you give me a clue please ?
|
Actually that telnet test should definitely have worked:
ghidora:~ daniel$ telnet login.live.com 443
Trying 65.54.183.203…
Connected to login.live.com.nsatc.net.
Escape character is ‘^]’.
^]
telnet> q
Connection closed.
and then from a box behind a nat
$ telnet login.live.com 443
Trying 65.54.179.203…
Connected to login.live.com (65.54.179.203).
Escape character is ‘^]’.
^]q
telnet> q
Connection closed.
So what you are telling me is that from this -exact same box- you can use Gaim and friends?
In fact I can’t telnet the url from my box or the server box.
I can log into msn messenger on windows in a third computer running windows.
I will work for the telnet to work and of course keep you inform. (seems this can’t work without it)
I’ve got some answers
First, I confirm that the proxy was shut down during hollidays (in case it goes down, users won’t be affected as few people would have been able to repair). That explains why it works for sometimes without me changing anything !
Moreover, the outgoing connection to http and https are dropped by my corp if they are not issued thourgh the proxy. That explains why I can’t telnet login.live.com:443 !
So we now have an explanation that seems correct. I will keep interested people in this thread informed when the networks config is updated.
Regards.
Of course, the best would that the IM plugin allows to wrap http/https to a proxy server
I must add that I tried launching openfre with JVM args:
(by editing the executable in openfire’s “bin” folder)
nohup “$app_java_home/bin/java” -server -Dhttp.proxyHost=mywebcache.mydomain.com -Dhttp.proxyPort=3128 -Dinstall4j.jvmDir="$app_java_home" …
But it is the same debug log output (is it not using the JVM preferences ??? -.-’)
Same result by setting http_proxy=“http://mywebcache.mydomain.com:3128” as system variable before starting openfire.
A few considderations:
I’ve had a look at the generated traffic. No port 80, 443, no udp. And again: With the same configuration with a direct connection to MSN by “kopete” i can connect. With “adium” (mac) i can’t and it complains about HTTPS connections. More or less the same behaviour the gateway shows but the gateway does not try to cummunicate by HTTPS.
Try to search for https and not 443 in your log.
Using tcpdump, I see the DNS resolution being made and the attempt to coonect thourgh https:
15:34:35.032540 IP myserver@mydomain.com.33966 > mydns.mydomain.com.domain: 11859+ A? login.live.com. (32)
15:34:35.033327 IP mydns.mydomain.com.domain >myserver.mydomain.com
.33966: 11859 2/4/4 CNAME[domain]
15:34:35.037592 IP myserver@mydomain.com.54551 > 65.54.183.203.https: S 3180817072:3180817072(0) win 5840
<mss 1460,sackOK,timestamp 2287791151 0,nop,wscale 2>
Where 65.54.183.203 is the ip resolved by a dns lookup of login.live.com (at least at the time I write this message (the string is https and not 443 in tcpdump, I think this is because it is a port under 1024 which is listed in /etc/services, so 443 is translated in https )
So I think the IM gateway DOES send the request. Can you confirm ?
Well https = port 443 as long as ther is no other port specified in the URL like https://www.secure.com:1234/ - with this the https request will be done by the port 1234 and not 443. If you do not specify the port https implies the usage of port 443.
try: tcpdump -n -i … - then no resolution of names of any type (DNS, services) will be done.
There is definiteively NO https traffic.