Hello all, I've been hunting for info on relaying UDP videoconferencing (Netmeeting) through my Linux router, with no success. I've come across a Microsoft article (here) which explains some of the rules necessary in any socks server to relay videoconferencing; I am in the midst of slogging through it. In a nutshell, the port information necessary is as follows: * Pass through primary TCP connections on ports 389, 522, 1503, 1720, and 1731. * Pass through secondary TCP and UDP connections on dynamically assigned ports (1024-65535). * H.323 is also mentioned, which means encrypted data and likely requires special software to achieve my desired end-result. There is some info I am reading up on at http://www3.openh323.org/ as well. I'm thinking I am missing something rather important, because this seems like a lot of hit-and-miss testing and configuration. Perhaps there is a piece of Linux software I've not found reference to in my searches. Who knows; I am learning as I go. This is my setup: -(cable modem)---Linux router (RH 7.3)---hub---PC (WinXP w/ webcam + NetMeeting) Any help or points-in-the-right-direction are appreciated. [edited by - MatrixCubed on December 4, 2002 10:18:48 AM]

I had some major issues a while ago getting Windows SMB to pass through a firewall. Problem had to do with it broadcasting to the high address on the network (eg 192.168.0.255). I had multiple firewalls on all machines on the network, and also a main firewall/router to the internet. I like to have the extra security inside my internal networks and I can easily see if they''ve been penetrated as the logs will show it pretty quick.

I can''t really help yahs much but maybe that video stuff relies on being able to broadcast to some address. I know some of that stuff uses multicasting and it might want to be trying to route to a blocked IP in your firewall.

The best thing to do is to run the application and then go to your router and look at your messages syslog files. Most likely it will report any violations on the firewall if you have configured properly to report these to the log file. This is by far the best means of debugging a firewall problem.

If you have a spare machine try setting it up as an intermediate router. This way you don''t have to plug up your main router and in case you screw up you can open an hole in it while you are configuring and some cracker might take the oppurtunity. That''s how I do my firewall stuff I test it first on a box and route it through the main firewall. Also makes it easier to find problems as you have more logs to look through.

G''luck