port forwarding

here are more details:
in the DNAT i have hte following rule:
  teamspeak   Any -> Dsl_Interface__ / teamspeak   None   server  
edit | delete
 


above that is my masquerading rule:
NAT   Internal_Network__ -> All / All   MASQ__Dsl   None  
edit | delete
 
My packet filter rule is:
Dsl_Interface__   teamspeak   Any   Allow
 
for teamspeak i have it as a service with the def of:
teamspeak   tcp/udp   0:65535   14536

[ QUOTE ]
My packet filter rule is:
Dsl_Interface__ teamspeak Any Allow

[/ QUOTE ] Bad filter rule.  Try this one instead:
Any teamspeak Any Allow

I somehow don't think your teamspeak traffic is originating at your Dsl_Interface.

interesting..actually all teamspeak traffic that comes from outside does originate fromt he dsl interface(that is my wan interface)..i connect directly to the server and bypass the asl box altogether..why would the above packet filter not work?  I will try changing it though..

[ QUOTE ]
interesting..actually all teamspeak traffic that comes from outside does originate fromt he dsl interface(that is my wan interface)

[/ QUOTE ]The NAT rule you printed in your memo does not do source address translation. Packet filters look at the source address in the packets. I am not familiar with the teamspeak software, but I do not see how any of the traffic using this protocol could possibly originate at the WAN interface of your ASL box. I suspect the traffic originates from other user machines out on the Internet, in which case you need to use Any as your source in your filter rules.

Are you perhaps confusing where the traffic is coming FROM, with the interface it is coming THROUGH?

nod more than likely..is there a way to use the snat/dnat to not have to use the source any packetfilter rule?

You can change the packet source address in any NAT rule. However, then the destination server will then no longer know where the packets are actually coming from. Both addresses and ports are reconfigurable via the DNAT/SNAT template in Webadmin.

However, wouldn't it be simpler to just use Any as the packet source in your filter rule? Creating the correct filter rule is a better approach than using NAT rewriting of source addresses to compensate for a flawed packet filter rule.

forwarding a port from an internet-connected interface to a server inside your internal lan is not  a quite good idea.
you'd better place your teamspeak-server inside the dmz if u wanna do port-forwarding.
another possibility would be to connect all your "team-members" via vpn and use filterrules based on the vpn-connections (i.e. based on the vpn's virtual-ip's)!


GoFast

or if your team-members have static hostnames, add them to your network, create a group, dnat - snat, packet filter rule. i do the same for my TS and it works great.

[ QUOTE ]
forwarding a port from an internet-connected interface to a server inside your internal lan is not  a quite good idea.
you'd better place your teamspeak-server inside the dmz if u wanna do port-forwarding.
another possibility would be to connect all your "team-members" via vpn and use filterrules based on the vpn-connections (i.e. based on the vpn's virtual-ip's)!


GoFast 

[/ QUOTE ]
I third nic would not work as this is also my file server.  When i get another mahcine to dedicate to the various other server tasks i plan on doing then i will be able to put it on another nic..[:)]  The machine has the latest kernel..the program runs as a non-priveldged user and uses strong passwords.  About all i can do in this situation.  My teammates are not static..many are on dialup. NOw i could be wrong but with the NAT rules i ahve setup the port i ahve opened should get routed to only the TS server and not hte internal lan in general..right or wrong?  Since NAT is performned before the packet filtering happens.

[ QUOTE ]
forwarding a port from an internet-connected interface to a server inside your internal lan is not a quite good idea.
you'd better place your teamspeak-server inside the dmz if u wanna do port-forwarding.

[/ QUOTE ]You are obviously a security purist, which is not such a bad thing to be.

However, the reality is that very many home users of today's user programmable routers will pragmatically open ports for custom Internet access to services running on their main machines. They are simply not going to commit an additional machine in a DMZ zone. It becomes simple economics, cost of additional hardware vs simple practicality combined with a slight security risk.

As an example, I run Bit Torrents on a Windows PC on my internal network.  Several ports are mapped from  that machine through  to my external ASL  interface, with filters to let the traffic through. I don't see the risk as particularly great that a hacker or worm will be able to exploit that fact. Home networks will also always tend to have  less security than professional installations, since they generally make do with less hardware for everything that they want to have running.  Good practicality with modest security risks becomes the solution for most.

The trick is simply to open up what ports you really need, and nothing more.