Port Forwarding problem

[mollyrush]

Not sure if this is the right forum but here it goes.

Hey Guys, I hope you can help me here! I've searched the forum and tried multiple fixes on the internet and still no luck.

I am trying to forward ports 6881 to 6999 from the clarkconnect (which is operating in gateway mode) to a LAN ip address running Windows XP SP2. I have applied a fix to the Win XP machine to allow 50 tcp/ip connections to the lan ip 192.168.0.252(which the xp box is operating on).


When I this command to list the open ports : iptable -L FORWARD

I get the following:

[root@gateway root]# iptables -L FORWARD
Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT tcp -- anywhere 192.168.0.169 tcp dpt:ftp-data
ACCEPT tcp -- anywhere 192.168.0.169 tcp dpt:ftp
ACCEPT tcp -- anywhere 192.168.0.169 tcp dpt:ssh
ACCEPT tcp -- anywhere 192.168.0.45 tcp dpt:kerberos
ACCEPT tcp -- anywhere 192.168.0.45 tcp dpt:3074
ACCEPT tcp -- anywhere 192.168.0.252 tcp dpts:6881:6999

drop-lan tcp -- anywhere anywhere tcp dpt:sunrpc
drop-lan udp -- anywhere anywhere udp dpt:sunrpc
drop-lan tcp -- anywhere anywhere tcp dpts:netbios-ns:netbios-ssn
drop-lan udp -- anywhere anywhere udp dpts:netbios-ns:netbios-ssn
drop-lan tcp -- anywhere anywhere tcp dpt:635
drop-lan udp -- anywhere anywhere udp dpt:635
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
DROP all -- anywhere anywhere

Still having these problem, I then decided to port scan the wan interface from outside, I did this using nmap. Nmap said that the ports were "filtered" which suggests that the ports are closed (or so I believe).

I have a script running to allow only the known mac addresses on the network to talk to the clarkconnect box but the computer at x.x.x.252 is able to talk to the clarkconnect box. Is there a bug or something that is prevent these ports being forwarded or could it be the script I have running ?

I have a proxy running on the CC box but I believe that only port 80 is going through it. I have tried turning this off in the hope that this would resolve the problem, but to no avail. Any help would be greatly appreciated?

Thanks in advance
Mike

[mollyrush]

I removed the script that was housed in /etc/rc.d/rc.firewall.local , this was the one that was causing the incoming client for bittorrent to be incorrect forward or denied, can anyone help me to edit this config so that an external client outside the lan can connect properly and forward data to the x.x.0.252 lan ip.

I am a bit of a linux novice so here it is down below

This is the script so far:

# Custom firewall rules.

$IPTABLES -t mangle -F maccheck
$IPTABLES -t mangle -X maccheck
$IPTABLES -t mangle -N maccheck

# if a request comes in, check its MAC by jumping to the maccheck table
iptables -t mangle -I PREROUTING -p all -j maccheck

# create the maccheck table of allowed MACs
allowed_mac="$IPTABLES -t mangle -A maccheck -m mac -j RETURN --mac-source "

# if any of these match the current MAC, we return from this table without
# doing anything

$allowed_mac 00:50:8D:F3:3F:9E #steve pc
$allowed_mac 00:00:86:35:58:1E #john laptop ethernet
$allowed_mac 00:07:E9:54:89:5B #gav pc
$allowed_mac 00:0F:1F:0E:4E:82 #bok laptop
$allowed_mac 00:30:18:2E:64:75 #bok linux
$allowed_mac 00:09:5B:C25:12 #steve laptop wireless
$allowed_mac 00:50:8D:5B:88:9E #Mike's PC
$allowed_mac 00:02:3F:75:91:73 #steve laptop ethernet
$allowed_mac 00:0d:3a:af:23:38 #Mike's Xbox
$allowed_mac 00:50:f2:da:d7:a0 #Bok's Xbox
$allowed_mac 00:0c:f1:53:d3:3d #Barry's laptop


# NEED TO ACQUIRE FOLLOWING MAC ADDRESSES:
#barry ethernet
#john laptop wireless
#john pc

$IPTABLES -t mangle -A maccheck -j MARK --set-mark 1
#$IPTABLES -t mangle -A maccheck -j LOG --log-prefix="set mark 1: "
$IPTABLES -t mangle -A maccheck -j RETURN


$IPTABLES -t nat -A PREROUTING -m mark --mark 1 -p all -j DROP



I'm a little happier that the torrent is working correctly but I am worried about the security issue as our wireless lan has been compromised on several occasions. I apologise to the cc developers for suggesting that this might be a bug