Messenger audio & video (how)

Ok well it may take a bit of tinkering but do this. create a new service. title it NetWrk-msn tcp/udp tcp 1 - 65535 6891 - 6900 (this is for file transfers if you want to allow more the 10 at a time increase the high number) udp 1 - 65535 6891 - 6900 tcp 1 - 65535 3389 - 3389 tcp 1 - 65535 5060 - 5060 tcp 1 - 65535 1503 - 1503 Now i could be wrong with the TCP and udp but microsoft was not intirely clear with this or i just (glazed) through it too fast. Make sure that you create a deny policy to be the last in the chain for INT-EXT with deny and logging this way you will know if you need to change the ports to udp. just watch the logs. Its always a good thing to do anyway.

Yeah robbo it is for ternimal service but i belive in the article msn also uses for the remote asistance. I was just listing everying that msn had and how to use it. Yonni port forwarding is designed more if you have 40 machines in a 192 subnet and only 1 real ip address. the easiest way i can describe it is to think of the firewall as a gate keeper. the incomming packet is routed to the firewall looking for 94.68.21.58 on port 8789 as an http packet. Now what the gatekeeper here dose is takes that info from the packet and sends it to computer 192.168.54.21:8789 but he will do this only if you have an incomming policy configured for this. Trust me if you ahve the ext to int policy configured routing to the VIP address for the interenal server there should be problem. Only time i have problems with with hardware devices.

I have a Frotinet 50a with a basic external 192.168.0.x and internal 192.168.1.x config. I have tried using the settings as detailed above, but no joy. I have even tried using both TCP/UDP 1-65535 1-65535 still no joy. I have added it as both internal-external, ext-int and both simulaneously still no joy. I know that the service works, as I have had both PCs on the external network and things are fine. I have not added any IP Pools nor Virtual IP Mapping. can someone help as I am pulling my hair out. I did have a 2 site VPN that was working on 50as a while back, but they stopped working earlier this year

Sounds like you need a special setup as with H323. When you have a VPN between the two machines that are trying to do video or voice it should be OK as the SIP messages go to MSN' s server to set up the call but the data streams will first try connecting directly, machine to machine. As long as there' s no additional NAT between the two machines it should work. If you don' t have direct communication between the two endpoints i.e. something is doing NAT between them, the Messenger client sends requests to the gateway device using uPnP to open up all the required ports. If like most half decent firewalls it ignores this request then the data connections will most likely fail. I think that some messaging services can get round the problem by proxying the stream via a server that' s accessible by both systems but I don' t think that works for MSN. I have heard that MSN is clever enough to work out if only one machine is NAT' ed and set that machine to open up the channels using normal stateful inspection rules. Bottom line, if both clients are behind NAT routers/firewall that don' t understand or obey uPnP requests then you' ve either got to restrict it to one machine and kill your security by opening loads of ports or live without it. More extravagent solutions involve setting up your own messenger server using expensive MS software. The only light at the end of the tunnel may be a feature I' ve noticed in a 2.8 beta. There is a command line setting for ' config system session-helper' which suggests that you can create your own helper rules where normal stateful inspection and or NAT bugger up applications. A typical application that goes wrong through NAT is PPTP and some implemetations of IPSec vpns. This is because the application opens up several sessions and not all of them are initiated using the same tcp/udp port combo or from behind the NAT in question. Consider PPTP: User behind NAT device with a PPTP client trys to VPN into his/her office. The laptop initiates a tcp connection using dest port of 1723. The vpn server than replies with a GRE tunnel - protocol 47. The NAT device is not expecting this apparently random GRE tunnel so it blocks it because it does not know that the initial tcp port 1723 connection is related as it doesn' t understand PPTP. Same applied to MSN. Video and voice conversations are setup using SIP I believe but this does not carry the actual data. The data streams try to get set up but because the NAT device doesn' t expect it the traffic is blocked. Hopefully, using this session-helper function we should be able to teach the FGs to understand more applications and allow the appropriate data channels to be set up once it sees the SIP traffic, in this case. Bit of luck they might have one pre-programmed!!!!

There' s hope! on 2.8 machine CLI: (session-hel.)# show config system session-helper edit 1 set name " pptp" set port 1723 set protocol 6 next edit 2 set name " h323" set port 1720 set protocol 6 next edit 3 set name " ras" set port 1719 set protocol 17 next edit 4 set name " tns" set port 1521 set protocol 6 next edit 5 set name " ident" set port 21 set protocol 6 next edit 6 set name " ident" set port 23 set protocol 6 next edit 7 set name " ident" set port 25 set protocol 6 next edit 8 set name " tftp" set port 69 set protocol 17 next edit 9 set name " rtsp" set port 554 set protocol 6 next edit 10 set name " rtsp" set port 7070 set protocol 6 next edit 11 set name " ftp" set port 21 set protocol 6 next edit 12 set name " mms" set port 1863 set protocol 6 next end I still can' t see how these inform the FG of what to do but this is a list of common applications that can have problems with a basic NAT implementation. The interesting bit in this case is the last one called " mms" that uses port 1863 and protocol 6 which translates into SIP and TCP - messenger call signalling.