Firewalls, Messenger, and VoIP Software - Oh the Horrors!

[Jason Dunn]

You know, I don't want to get off on a rant here [dim lights], but I have to get this off my chest. It staggers the imagination how badly big companies can screw up even the simplest of things.<br /><br />Once again I find myself insanely frustrated with Microsoft and their software/hardware. :evil: Here's the short version: I have an MN-500 firewall/gateway device, which is touted as having a Universal Plug-n-Play firewall that dynamically opens up the correct ports for client-side apps that need access. Great in theory, works quite well most of the time. But I was unable to get file transfers working with a friend of mine. We were both using Windows Messenger 4.7, and he was behind a Linksys firewall. After months of struggling with this configuration, he went out and bought a Microsoft firewall/gateway (the MN-100). He also reformatted and installed XP Home, and I was on an install of XP only 24 hours old. We both had Messenger 4.7, UPnP firewalls, and tried to transfer a file. You'd think such an "out of the box" set up would work, right? No dice - no file transfers would occur, even though we confirmed that the correct port ranges were open.<!><br /><br />We then bypassed our gateways, connected directly to the 'Net, sans firewall. The result? Perfect file transfers. I went behind my firewall, he stayed out in the open, and I was able to receive files from him, but not send. Augh! 8O I gave up and did something I very rarely do: called tech support. An hour later, we established that Windows Messenger 4.7 will cannot send files from behind a Microsoft firewall to another 4.7 user behind a Microsoft firewall. I upgraded to the much-reviled MSN Messenger 5.0, and I was able to send him files from behind my firewall. Huh? "Oh," says the tech "there are some problems with Messenger 4.7 not working properly behind a Microsoft firewall." Oh, ok, sure - I must have been naive to think that a Microsoft product would work well from behind a Microsoft firewall. Silly me. :roll:<br /><br />Once we were both running MSN Messenger 5.0, each behind our respective firewalls, we were able to send and receive files without difficulty. Hooray! But as soon as he switched back to Trillian, he was unable to receive files from me. AUGH! :evil: So now he keeps MSN Messenger installed JUST for me, his one contact who needs send/receive file transfer access. How pointless is that? Ultimately that's a Trillian problem, but it underscores the complete mess that the instant messaging world is today. Nothing works with anything else!<br /><br />Now we come to the <b>really ugly part of the story:</b> my pal and I play online games together (Diablo 2, Age of Mythology, Neverwinter Nights, etc.) and adding voice into the mix adds a great deal of fun. We've used a few different solutions, but for the past year we've been using Microsoft's free <a href="http://www.gamevoice.com/Download/download.asp?Page=146">Game Voice 1.5</a> software. It integrates nicely with Windows Messenger, and works quite well. I installed it, fired it up, then tried to chat with my friend - only to have the buddy list window be blank. AUGH! :evil: After a bit more research, I discover that Game Voice 1.5 is a dead-end product. It's not compatible with MSN Messenger 5.0, and Microsoft has no plans to make it compatible. Grrr. MSN Messenger's voice chat functionality doesn't work through NAT firewalls.<br /><br />Foiled at every turn! For the love of all things holy, <i>what the HELL are the people at Microsoft thinking?</i> The scenarios I described above seem quite mundane, yet the Microsoft solutions fail at every turn. Do they test their software before they ship it? If so, under what circumstances? Because it sure mustn't be "Person A wants to talk to Person B". Nooo, that would just be too CRAZY to even try, right?<br /><br />Anyway, the point of this long rant is not only to make myself feel better, but also to ask a question: what voice chat software is out there that works well, especially over NAT-based firewalls?<br /><br />Rant over, but I swear, if I ever encounter the Microsoft product managers responsible for these broken scenarios, I'll have some strong words to say to them.

[Daniel]

Ok, NAT is usually the problem in these sorts of situations. It just doesn't work very well for these sorts of things. I had the same problems sending files to my brother. I think that it's just the nature of the beast not necessarily a Microsoft thing.

I would also love to be able to make some Mac Zealot comment but unfortunately there are very few if any Voice Chat solutions for the mac which is a real pain. I would love to have a video chat with my brother but I can't.

Good Luck.

Daniel

[Macguy59]

Ok, NAT is usually the problem in these sorts of situations. It just doesn't work very well for these sorts of things. I had the same problems sending files to my brother. I think that it's just the nature of the beast not necessarily a Microsoft thing.

I would also love to be able to make some Mac Zealot comment but unfortunately there are very few if any Voice Chat solutions for the mac which is a real pain. I would love to have a video chat with my brother but I can't.

Good Luck.

Daniel

Daniel, have a look at ivist. It has clients for Windows and OS X (beta)

http://www.ivisit.com/

[PDAC-Bob]

:( @ Woes, I know the feeling.

IMHO as an ex-field service engineer, there are very few products which are pure plug and play. (Oh what an ideal world that would have been - but I would have been out of a job :? )

Messenger is a bit of a strange beast. I have encountered similar problems with file transfers and voice chat. An interesting recent discovery however, revealed that the gamevoice does not seem to appreciate certain Bluetooth stacks! This moreover seems to also affect the initiation of file transfers too.

In testing, we discovered that if the initiating party were to remove thier bluetooth adaptor, or disable it, voice and file transfers were fine. Throw a Wi-Fi network into the equation however, and Messenger can cause real headaches, even trying to just locate what is causing the problem.

NAT (Network Address Translation) doesn't always seem to pose a problem for everyone, and some setups with NAT and a firewall operate just fine. It is this I think, that causes mass confusion and can inevitably lead to the "Well we know plenty of people who are using it without any trouble..." scenario. You bang your head against the wall, and otherwise perfectly usable kit (a la GameVoice) gets retired to the 'Maybe I'll look at it another day' box.

Don't know if it'll help any, but little while back there was an interesting article on NAT and Messenger by Greg Schultz @ CNET: http://asia.cnet.com/itmanager/tech/0,39006407,39092525,00.htm

You never know, may cast a little more light on where to look next, especially regarding the 'cascading' issue which he talks about.

Regards

Bob

[Daniel]

Daniel, have a look at ivist. It has clients for Windows and OS X (beta)
http://www.ivisit.com/

That's one but it's Classic only and no Audio. Thanks for the link but that goes in the "Not worth it" category. Hopefully the rumors about Apple putting Video Conferencing in iChat are true.

Daniel

[Janak Parekh]

Ok, NAT is usually the problem in these sorts of situations. It just doesn't work very well for these sorts of things. I had the same problems sending files to my brother. I think that it's just the nature of the beast not necessarily a Microsoft thing.
Indeed, NAT is a big impediment to VoIP and related data applications. If you talk to VoIP researchers, they hate NAT. Longterm, the move to IPv6 will enable us to eliminate NAT entirely and solve the problem once and for all. While there are workarounds (like using the UPNP firewall), they're going to remain dicey and implementation-specific for some time. :cry:

This doesn't make Jason's rant any less true, though. Microsoft's piecemeal approach to developing workarounds is immensely frustrating. We recently set up Three Degrees (http://www.threedegrees.com/) in our office and while it's cool, NAT totally breaks it. Even though it's using MSNM 5. Sigh...

--janak

[Citezein]

So here's some technical info for you. Windows Messenger 4.7 does not use UPnP to send files. It uses UPnP for the video confencing only. MSN Messenger 5.0 does utilize UPnP for file transfers, which is why it works with your new MN-500. Microsoft is working on Windows Messenger 5.0 which will use UPnP for file transfers. Why they didn't release it at the same time as MSN Messenger is a mystery to me.

You can use 4.7 for file transfers with some routers. From what I have been told, the Linksys line of routers actually recognizes the Windows Messenger file transfer and automatically rewrites the packets in order to allow file transfer. I too bought a MN-500 and was stuck by this bug. I don't know what to tell you about the GameVoice though. Last I heard Trillian to MSN file transfers did work. Make sure you've downloaded the latest Trillian patches, and the latest firmware for the MN-500. I think 1.08 is the newest and is vastly superior to the shipping version.

Good luck.

[Jason Dunn]

So here's some technical info for you...

Very interesting, thanks! I'm running 1.08 - whenever things don't work, that's the first thing I try - patches, upgrades, etc.

[Oregon Trail]

I'm not an IT person, just a regular consumer. But what is important is that a product works reliably. I don't care how it works, just that it does. That is my problem frequently with computers, they don't work the way I expect them to, and by extension what many other consumers feel. When major companies like Microsoft figure that out, the world will be a better place.

[cherring]

Since when is a firewall supposed to be a consumer friendly device?

[DrtyBlvd]

Since when is a firewall supposed to be a consumer friendly device?

ROFL - How exceptionally true :lol:

[brianchris]

Don't mean to throw more confusion into the witches brew (or perhaps it is just I who is confused), but some questions:

- Where did everyone get MSNM 5? It must be in beta and the tech gave it to you for troubleshooting your problem Jason?
- I'm running WinXP (Pro), and have noticed there are at least to versions of messenger: MSNM for Windows and Windows Messenger for Windows XP......which one is at the 5.0 level (beta or not)? For what its worth, I'm running Windows Messenger 4.7 on my WinXP machine, and I thought it was the most current :?:
- File transfers and Messeneger voice service would be great through NAT, but what I REALLY need to work through NAT reliably is XP Remote Assistance......any word on if that is improved through NAT with MSNM 5.0?

I am running a Linksys Router that (supposedly) has UPnP ability. While it has improved NAT tranversal problems a little bit, it certainly didn't solve all my problems. Thanks in advance!

-Brian

[Jason Dunn]

Since when is a firewall supposed to be a consumer friendly device?

When it's a Universal Plug and Play firewall that dynamically opens up ports as needed - that's the whole point. :wink: Every software vendor should be working very hard to make their products work nicely through firewalls, because if you have a broadband connection, they're an absolute necessity. I install software or hardware firewalls on every computer I ever sit down at, and I suspect that I'm not unusual in doing that.

[brianchris]

Since when is a firewall supposed to be a consumer friendly device?

I install software or hardware firewalls on every computer I ever sit down at, and I suspect that I'm not unusual in doing that.

Your not unusual.....clients / relatives / friends of mine who have broadband with no firewall / router get the whole "unprotected sex" analogy lecture from me 8)

-Brian

[Jason Dunn]

- Where did everyone get MSNM 5? It must be in beta and the tech gave it to you for troubleshooting your problem Jason?
- I'm running WinXP (Pro), and have noticed there are at least to versions of messenger: MSNM for Windows and Windows Messenger for Windows XP......which one is at the 5.0 level (beta or not)? For what its worth, I'm running Windows Messenger 4.7 on my WinXP machine, and I thought it was the most current :?:
- File transfers and Messeneger voice service would be great through NAT, but what I REALLY need to work through NAT reliably is XP Remote Assistance......any word on if that is improved through NAT with MSNM 5.0?

1) You can download it here (http://messenger.msn.ca/download/download.asp?client=1). It's not in beta - it was released about two months ago.

2) Yes, Windows Messenger 4.7 is the most current version of Windows Messenger, while MSN Messenger 5.0 is the most current version. They're two seperate products with slightly different functionality.

3) Using Messenger 4.7 with an MS firewall on both ends, I've used remote assistance several times with zero client-side configuration. It's the ONE thing that actually worked well! 8O

[IanG]

I don't know if this suggestion will work or not, but how about using MS Portrait?

I know it works from my NAT/Firewall box to non-NAT machines, but don't have 2 NAT-ed boxes to test with. I think you'd have to set up port forwarding on one of the NATs, and then try to connect from the non-forwarded PC to get it to work.

Sorry if this is the lamest suggestion of the day though :roll:

Later

Ian G

[brianchris]

- Where did everyone get MSNM 5? It must be in beta and the tech gave it to you for troubleshooting your problem Jason?
- I'm running WinXP (Pro), and have noticed there are at least to versions of messenger: MSNM for Windows and Windows Messenger for Windows XP......which one is at the 5.0 level (beta or not)? For what its worth, I'm running Windows Messenger 4.7 on my WinXP machine, and I thought it was the most current :?:
- File transfers and Messeneger voice service would be great through NAT, but what I REALLY need to work through NAT reliably is XP Remote Assistance......any word on if that is improved through NAT with MSNM 5.0?

1) You can download it here (http://messenger.msn.ca/download/download.asp?client=1). It's not in beta - it was released about two months ago.

2) Yes, Windows Messenger 4.7 is the most current version of Windows Messenger, while MSN Messenger 5.0 is the most current version. They're two seperate products with slightly different functionality.

3) Using Messenger 4.7 with an MS firewall on both ends, I've used remote assistance several times with zero client-side configuration. It's the ONE thing that actually worked well! 8O

My obvious next question was what's the difference between Windows Messenegr and MSN Messeneger, however I got that question answered here (http://messenger.msn.ca/support/helphome.asp?client=1#Q1b).

From that review of the two above, it would seem like Windows Messeneger is the prefered client (Remote Assistance using it as default, ability to connect to Exchange Messaging Servers, etc., etc.). Hopefully it will have the NAT Tranversal upgrades that MSNM 5.0 has soon. Any other reasons to be using MSNM over windows Messenger?

Alas, I've experience more problems than not when trying to use remote assistance. However, perhaps a difference between us is that I attempt remote assistance sessions with all different types of people (again, clients / family / friends) with all different types of Internet connections and / or firewalls - routers. Sounds like you only have initiated them in one type of enviornment (i.e. two microsoft routers).

Better NAT transversal would seem to be a holy grail quest for the moment. Although, I would like to learn more about Janek's IPv6 comment.....any recomended resources? Thanks!

-Brian

[mv]

Since when is a firewall supposed to be a consumer friendly device?

Since consumers are buying these things. I have the same problem, i can´t transfer files on MSN... i don´t care anymore, i can accept than most MS things just won't work. That´s life. Makes me wanna get rid of my pc and my ipaq, and then buy a nice mac and a palm. Some of these days, i´m sure i will.

[sweetpete]

Anyway, the point of this long rant is not only to make myself feel better, but also to ask a question: what voice chat software is out there that works well, especially over NAT-based firewalls?


To answer your original question ... Roger Wilco (http://rogerwilco.gamespy.com) is the answer. It's been around for ages and it generally works well with NAT's and firewalls. There is some OK help and support files for configuring it if things shouldn't work.

I've used it on and off for a few years whenever I get into the game playing mood.

[Janak Parekh]

Although, I would like to learn more about Janek's IPv6 comment.....any recomended resources? Thanks!
You mean, on IPv6? How about A Google search (http://www.google.com/search?q=ipv6)? :)

A short explanation as to what I said before: IPv6 increases the address space. A lot. A whole freaking lot. Let me put it this way: IPv6 uses a 128-bit address space, which allows for, theoretically speaking, 3.40 x 10^38 unique IP addresses, or as a Microsoft primer (http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/proddocs/server/sag_ip_v6_imp_addr1.asp) puts it, 6.5 × 10^23 unique IP addresses for every square meter of the earth. Not all of these are useable, but you get the point.

In other words, we don't need to use "fake" private NAT IP addresses -- when you want to call someone, you know their exact IP address. Firewalls are still a problem, but it's overall much easier to work with if the machines are directly addressible.

--janak

[mattman]

NAT is not actually the problem here, what is the problem is developers that write software that embeds the source address of the machine within the payload of the tcpip packets. This forces the NAT implementation to have to read right into the packet to try and pick this up and then rewrite the packet. This requires knowledge of the particular app so they need support by the developers.

Most software if it has been written well will work through many to one nat with no drama's at all.

Matt.

[JvanEkris]

Jason,

Have you read this article (http://www.microsoft.com/windowsxp/pro/techinfo/deployment/natfw/) from micro$oft, perhaps it helps.

Jaap

[cherring]

If you have a correctly configured firewall, the software shouldn't even be aware of what the firewall is doing to work. I have a PIX firewall running and I invite anyone who has any problems and would like to do some testing or actually working through this problem to get in touch with me so that we can have some kind of resolution to post on. How about that?

[Janak Parekh]

NAT is not actually the problem here, what is the problem is developers that write software that embeds the source address of the machine within the payload of the tcpip packets. This forces the NAT implementation to have to read right into the packet to try and pick this up and then rewrite the packet. This requires knowledge of the particular app so they need support by the developers.
Well, there are two problems with your assertion:

1. How exactly do you exchange IP addresses with peers, then, if you're not opening a socket to them?

2. How do you open a connection to a machine behind a NAT router? How do you address it?

In the MSNM scenario, usually two users are talking to each other via MSN's servers. If they want to do a file transfer, they have to establish a direct peer-to-peer connection. To do this, they exchange connection information, e.g., IP addresses, via MSN's servers. The fact that NAT can't rewrite these because they're in the payload highlights the limitation (and evils) of NAT: IP addresses weren't originally intended to be rewritten! This whole "hack" exists because we're running out of addresses in IPv4. It's a very clever one, but it has its limitations.

With IPv6, an ISP can trivially give you, say, 1,024 real, routable, IP addresses for your use. Then you don't need NAT, just firewalling.

--janak

[mattman]

You use static nat entries to direct inbound connection requests on certain ports to specific machines behind your firewall. This might mean that you can only have one session of a particular application running but it will still work if it has been written well. If you had two machines behind your nat/firewall possibly only one could use MSN Messenger to send/receive files for example.

IP Addresses can still be exchanged without embedding the source address in the payload, when you talk to the MSN servers your source address is still the valid external real address, it doesn't need to be in the payload for MSN servers to be able to see who you are, that's just bad design in my opinion. The only time NAT should really be a problem is when you need direct client to client connections.

The assumptions everyone is making about IPV6 is that all the ISP's will be able to change their networks to support routing subnets out to each dsl/cable connection rather than just a single address. IPV6 will certainly solve a number of problems but with it it will bring many many more, mainly on the infrastructure side with respect to implementation and management.

Matt.

[Janak Parekh]

You use static nat entries to direct inbound connection requests on certain ports to specific machines behind your firewall. This might mean that you can only have one session of a particular application running but it will still work if it has been written well. If you had two machines behind your nat/firewall possibly only one could use MSN Messenger to send/receive files for example.
Exactly. That's not really a long-term solution when large-scale VoIP is deployed, or if you have a household with multiple computers. Ergo, the UPNP firewall hacks.

IP Addresses can still be exchanged without embedding the source address in the payload, when you talk to the MSN servers your source address is still the valid external real address, it doesn't need to be in the payload for MSN servers to be able to see who you are, that's just bad design in my opinion.
It's not there for the MSN servers, it's there for the peer (the MSN servers just use your established TCP connection, so they could care less about the address per se). I guess you could have the MSN servers grab the source IP address and then turn around and send it to the peer in the payload, but that's pretty nasty too.

The only time NAT should really be a problem is when you need direct client to client connections.
...which is what the whole point of this thread is. :)

The assumptions everyone is making about IPV6 is that all the ISP's will be able to change their networks to support routing subnets out to each dsl/cable connection rather than just a single address.
There's nothing special about this. Either you're routing a /31 (which is effectively a single IP), or something larger than it (of course, in IPv6 you can route /127s :D)

IPV6 will certainly solve a number of problems but with it it will bring many many more, mainly on the infrastructure side with respect to implementation and management.
Oh, absolutely. But we need to upgrade sometime soon, and not only because of the address crunch. All the major OSes now support it, and all of the new routers do. I'm not saying it's going to solve Jason's problem tonight, but long-term it's an effective, superior solution as opposed to NAT.

--janak

[mattman]

The main point of my post, and yes there is one hehe, is that NAT is not evil and as long as the software development has been done properly and has taken into account the current infrastructure limitations generally everything can work quite well.

Whilst there are a lot of client to client type apps emerging there still needs to be a gatekeeper type of service to broker the connections and if this is architected properly then there is no problem with multiple PC's running behind a single IP address.

With most current implementations you aren't routing really, a /32 address is allocated via ppp to the interface visible to the ISP, having a routable subnet behind the dsl/atm/cable interface is quite different to how things are done now and is a lot more complex, not impossible but there is a lot of work required to implement IPV6 that a lot of people aren't really aware of.

IPV6 is definitely the way of the future however there is still a lot of work to be done before we begin to see commercial consumer offerings based on IPV6 - whilst product support is available now there are a number of issues with most products that are out there now, mostly performance. These issues will be solved but they are still quite a way off.

Matt

[Janak Parekh]

The main point of my post, and yes there is one hehe, is that NAT is not evil and as long as the software development has been done properly and has taken into account the current infrastructure limitations generally everything can work quite well.
Well, I don't mean evil literally. But NAT does remove the original notion of IPs corresponding to nodes, which breaks a lot of protocols. You can design fancier protocols to work around it, but we shouldn't have to.

Whilst there are a lot of client to client type apps emerging there still needs to be a gatekeeper type of service to broker the connections and if this is architected properly then there is no problem with multiple PC's running behind a single IP address.
This is really application-dependent, IMHO.

With most current implementations you aren't routing really, a /32 address is allocated via ppp to the interface visible to the ISP, having a routable subnet behind the dsl/atm/cable interface is quite different to how things are done now and is a lot more complex, not impossible but there is a lot of work required to implement IPV6 that a lot of people aren't really aware of.
Ah, didn't think about the PPP angle. All the networks I use are subnet-routed and not /32s. Yes, that would be infrastructure hell... that's why I'm not saying the IPv6 upgrade is happening tomorrow.

Anyway, we should probably put this discussion to bed. :)

--janak

[DrtyBlvd]

Hablo Inglese?

[Jason Dunn]

The main point of my post, and yes there is one hehe, is that NAT is not evil and as long as the software development has been done properly and has taken into account the current infrastructure limitations generally everything can work quite well.

True. But my point was that even through my friend and I were using Microsoft products, end to end (firewalls and IM clients), it STILL wouldn't work. As a cosumer, I don't particularly care why it "should" work, but just that it doesn't. :wink:

[PeteTh]

Just to add some more to the pot, do you guys know about SIP, I believe this is alternative way to get around the NAT problem using SIP instead uPnP, but you need a SIP enabled router.

http://www.fordyce.uk.com/intertex/importanceofsip
http://www.fordyce.uk.com/intertex/whatissip
http://www.intertex.se/index2.asp?iMenuID=268&iItemID=212

[Janak Parekh]

Just to add some more to the pot, do you guys know about SIP, I believe this is alternative way to get around the NAT problem using SIP instead uPnP, but you need a SIP enabled router.
Well, as you imply, this can also be a solution, but you do need a SIP proxy at the NAT/firewall edge, whether it's bundled in the router or not. I think we'll see both SIP and IPv6 happen in the next 3-6 years, but growth until then will be slow.

--janak

[iPaqDude]

All this fun and games... just wait until you decide to upgrade to Windows .NET...er, I mean Windows 2003.

Of course Microsoft is saying that everything will work with everything, and that you can eat your cake too...

Ummm.... I have some prime real estate out in the middle of the Green Swamp in Central Florida that I would be happy to sell you... :wink:

[Janak Parekh]

All this fun and games... just wait until you decide to upgrade to Windows .NET...er, I mean Windows 2003.
Of course not everything will work, but I can say that Windows Server 2003 is a pretty slick piece of software (I've been playing with the .NET Release Candidates). It'll be a very nice step up from W2k.

--janak