1

I'm pretty stumped with this, I've been messing around with it for hours with no joy - I know it'll be something stupid I've missed.

At our old office we have a Netgear DG834PN router which has several port forwards set-up - several to a Server 2003 machine running there and a few to a backup NAS machine.

All of this was working fine until the other week. I did install DHCP server on Server 2003 but I've since unauthorised/stopped that so it shouldn't be doing anything any more. Everything has been rebooted since.

Port forwards work fine to the office server but fail to other machines. I've even tried redirecting port 80 from Server 2003 (which works fine) to another machine (which has port 80 open) and it still fails - I've confirmed this by trying to connect from several outside locations.

From within the network or via remote desktop to the server I can access everything, if I VPN into the server I can access everything (both bypassing NAT I presume).

SSHing into the router or looking at its logs in the web admin everything looks ok, it's going to the right IP, the right port, and the clients shouldn't be blocking the connection (they weren't before, and neither can I see anything in their logs) but the connection never happens. I've tried testing with web browsers, FileZilla and telnet.

Here's a log from the router when I try to connect to a working port forward rule to Server 2003 (HTTP) and a non-working port forward rule to the backup NAS (FTP, running on port 2121 - but the ports/protocols seem irrelevant):

// server 2003, works
Sun, 2011-05-15 00:22:04 - TCP Packet - Source:88.110.x.x,32444 Destination:192.168.0.7,80 - [HTTP match]
// NAS machine, fails (2121 is the correct port)
Sun, 2011-05-15 00:21:41 - TCP Packet - Source:88.110.x.x,32443 Destination:192.168.0.90,2121 - [FTP_NAS match]

Here's the entries in iptables from the router (they were configured with the web UI) for port 2121 (I've substituted our real domain name with example.co.uk):

# iptables --list | grep :2121
LOG        tcp  --  anywhere             anywhere           state NEW tcp dpt:2121 LOG level warning prefix `[FTP_NAS match]'
ACCEPT     tcp  --  anywhere             nas.ads1.example.co.uktcp dpt:2121

Does any one have any more ideas? Thanks in advance!

Improve this question
2

Are your default routes at the hosts in question still going through the DG834? If you messed with DHCP, you might have changed that.

Apart from that I'd suggest using a protocol sniffer like Wireshark to check if a) your requests are forwarded correctly to the hosts b) the requests initiate responses c) the responses are directed to the MAC address of the DG834

If all of this applies, you probably will be having some kind of filtering in place which prevents your outgoing traffic to pass.

Improve this answer
7
  • I had originally been using Wireshark and I could see ARP requests of who has 192.168.0.90 Tell 192.168.0.7 (192.168.0.90 = NAS, 192.168.0.7 = Server 2003) which was when I disabled the DHCP server. Since then I can't see anything of major interest apart from a few who has 192.168.0.90 Tell 192.168.0.1 (the Netgear router) and the odd broadcast from the NAS to the whole network. Presumably I need to be able to run Wireshark on top of the Router to get the most information out of it? – akiller May 16 '11 at 9:38
  • 1
    Nah, it would be sufficient to fire up wireshark on a host where port forwarding does not work. Just start it up, try a connection to a forwarded port and watch for the TCP SYN packet to hopefully arrive at the destination host and generate a SYN/ACK response. The router probably would not support any kind of packet capture unless you exchange the firmware for an open project like OpenWRT. – the-wabbit May 17 '11 at 10:49
  • I might have missed what you want me to do, however from my home PC if I watch Wireshark when I try and telnet to broken ports I can see SYN requests but no ACKs. If I telnet to a working port I can see SYN/ACK (and telnet will connect). I am seriously tempted to go and stick the DGTeam firmware on it (I use it on my home router and it works well). – akiller May 17 '11 at 11:58
  • You should be running Wireshark on the destination host (i.e. the machine that the port forwarding is set up to, like 192.168.0.90) to check if the SYNs your home PC is sending do in fact arrive there. – the-wabbit May 17 '11 at 12:06
  • Ah. That's a ReadyNAS Linux box and I don't have Wireshark on it (or the knowledge to get it on there quickly). I've managed to fix the problem though (see above), thanks a lot for your help. – akiller May 17 '11 at 12:45
0

"From within the network or via remote desktop to the server I can access everything, if I VPN into the server I can access everything (both bypassing NAT I presume)."

You might examine the individual servers more closely at their firewall rules to ensure there is nothing there limiting access to only from internal addresses. A look at your working server can also verify how the external access is normally logged (internal vs. external address(es)).

Improve this answer
1
  • Thanks for your answer. Everything is connected direct to the router and doesn't go through Server 2003 at all (it makes it easier to pull out the server to another location if need be). I did add a port forward rule to RRAS just to see if it worked but it didn't. – akiller May 16 '11 at 7:05
0

Fixed! As I know how annoying it is when someone doesn't leave an answer I'll explain what I did.

It looks like what happened was that on the backup box (a Netgear ReadyNAS) it had lost its gateway settings which must have meant that it got confused and couldn't route the data back to the remote hosts (but had no problem doing it internally).

I started to get a bit suspicious when I could ping internal sites from the NAS but when I tried to ping an external site I got an error:

NAS:~# ping www.google.com
connect: Network is unreachable

I have SSH access to the box so when I ran:

route -nee

I would get the following response:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface    MSS   Window irtt
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0     0     0      0

When Googling around for information on this I read somewhere that there should be an entry to map the 0.0.0.0 gateway address to the router.

Once I added the gateway IP back to the NAS I got the following output:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface    MSS   Window irtt
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0     0     0      0
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0     0     0      0

Resulting in both being able to ping from the NAS and port forwarding working straight away.

Presumably this must have happened to the other hosts I tried to port forward to as well.

Thanks all for your help, it pointed me in the right direction.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.