MSN Messenger Voice Rules?

[Dan Perez]

Hi All :)

Has anyone successfully got this to work within LnS? I am still looking at other alternative implementations but I have been able to get this to work thus far only by creating a generic allow for remote TCP 1863 and then allowing all UDP from the remote party's specific IP but this is less than ideal, particularly depending on how often our respective IPs change.

After allowing TCP 1863 and before allowing all UDP I found from the logs that remote UDP 1900 and remote UDP 7001 were blocked (these are from various MS servers) so I made a rule allowing these, but as soon as I attempted a voice session I began getting a slew of higher UDP to higher UDP packets from the IP of the other party. The ports used are random for each session but seem to stay within the same ports once a given session is established.

It would seem to me that one or more of the other three ports that are consistent across MSN sessions are control channels and that when a UDP voice session is negotiated each side has to agree on which port to receive on and if there is any makeshift UDP "Stateful" provision in LnS this might be applied here. But I do not know of any. Is there anything that I am missing in my approach to this issue?

Any input would be greatly appreciated ;D

Also :) , on an unrelated point, is there any means for establishing IP address/range variables that can then be envoked within the various rules (rather like the implementation in Snort)? This would mean that whenever there is a group of rules that are intended to apply to a certain address, or group of addresses and whenever that address changes one merely has to change the variable definition rather than go to each corresponding rule and edit there.

TIA

[FluxGFX]

Yes it works, you need to create 2set of rules for msn messenger voice access and video access on ... dont remember the port range ( TCP/UDP also ) ask phantom about it thought.

[Dan Perez]

Ah, cool, I'll stop wracking my brains then and wait for phant0m`` to return ;D

Thanks for the confirmation

[FluxGFX]

If I was home Dan I would help you with the information that you need regarding this, I set it up on my pc ;)

but thats what I get when Im not home ;) damn damn damn ;)

[Dan Perez]

Any input from anyone on the original post in this thread?

According to an MS document found here;

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/winxppro/deploy/worki01.asp

speaking of the voice sessions...

-{ Quote: "The actual Real-time Transport Protocol (RTP) streams are sent using dynamically allocated UDP ports in the range of 5004 ? 65535. Without a way to open these UDP ports on any firewall in the path dynamically, the streams will fail to reach their destination.
" }-

So if one were to merely open up all the possible ports one whould have to really open up a huge range on the UDP side of things.

This is assuming, however, that there is no reg hack available to confine the random port selection to a much narrower range, or that the firewall has no workaround in place to mimic "stateful" behaviour over the inherently stateless UDP.

Thanks,

Dan

[Dan Perez]

any thoughts, anyone?

[Frederic]

Hi Dan,

To avoid having a lot of UDP port open all the time, you can add the MSN application to the Internet Filtering rule you added.
Doing that, the rule will be activated only when the application is running.

Frederic

[Dan Perez]

Hi Frederic,

Thanks for the input! Yes, I was looking at doing that but I am considering an alternative set of rules so as to workaround the need to update the IPs for the main UDP allow rule on each end. This would be to allow a generic allow rule for UDP in the range specified by the MS article but without tying it to any IP and we would just enable that rule only when we are about to start the Voice session, and then re-disable it on completing it. This would not be as secure as tying the UDP allow rule to a specific IP but would require less babysitting for connections that change IPs frequently. I'll post the rule details here once I get it tested so anyone searching the forum for solution to the MSN6 Voice issue would have a solution to try.

Thanks! :)

Dan

[Phant0m]

Most has MSN Messenger running full time, and so adding MSN to the Look ‘n’ Stop’s rules App-list would be quite misleading.