WAN-LAN throughput & firewall issues

[ipaq]

My new N66U has arrived a few days ago and I am now testing it and have found a couple of issues, in both the factory 3.112 firmware and the latest 4.260.

The very first problem I encountered is its ethernet ports (all ports including WAN) aren't playing nice with NICs with Realtek RTL8169 controllers in Linux (haven't got time to test it in Windows) - link speed auto-neg always fails and the link state flip-flops frequently, and eventually the router will crash and become inaccessible even from the LAN side. The only remedy is to switch off autoneg and force 100/full duplex from the NIC side - but then that's 1/10th of the full speed. I tried the et command (equivalent to ethtool?) in the firmware to set link speed but also to no avail. The cables are all Cat6 tested, and the same NIC/cable combo negotiates perfectly with other switches and network devices. To be fair, my other Intel giga NICs have no problem whatsoever when plugged into N66U. Any chance the router is at fault here?

Granted, I proceeded to test the WAN-LAN throughput. Using iperf and Cat6 cables and NICs that have no link speed issues, I was only able to obtain approx 250Mbps in either direction and simultaneous both way transmissions when WAN NAT is off. It is rather low when compared to the various benchmarks on the net citing something like 700+ Mbps. Strangely when NAT is on, the WAN-to-LAN speed jumped to 900+ Mbps (while the other direction remained the same at ~250Mbps.) I reckon it has something to do with the LAN acceleration (not disabled). QoS and Firewall didn't seem to have any noticeable effect on throughput. The question is, how can I increase the throughput?

The last issue is the iptables rules. No matter what the "Firewall" settings is, external packets from the WAN side can be routed to any internal interface, be it LAN or WLAN. This seems like a security problem to me. This is my FORWARD chain:

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
0 0 DROP all -- !br0 eth0 anywhere anywhere
0 0 DROP all -- any any anywhere anywhere state INVALID
0 0 ACCEPT all -- br0 br0 anywhere anywhere
0 0 ACCEPT all -- any any anywhere anywhere ctstate DNAT

You see the default FOWARD policy is ACCEPT. Anything from eth0 (WAN) to br0 (LAN) match no rules here and will hit ACCEPT and will leak through. Shouldn't it look more like this instead when Firewall is on? Or am I missing anything here?

iptables -P FORWARD DROP
iptables -D FORWARD ! -i br0 -o eth0 -j DROP
iptables -I FORWARD -i br0 -o eth0 -j ACCEPT

[RMerlin]

That last rule will NAT any packet that hasn't matched any rule yet:

0 0 ACCEPT all -- any any anywhere anywhere ctstate DNAT

So you should never have unmodified packets forwarded by the default rule.

[ipaq]

RMerlin,

Originally Posted by RMerlin

That last rule will NAT any packet that hasn't matched any rule yet:
So you should never have unmodified packets forwarded by the default rule.

I'm afraid that's not the case. I ain't too familiar with the ctstate matching, but from what I gather the last rule would only match and accept those packets that have already been DNAT'ed per conntrack's state entries.

I have observed in my tests that none of these FORWARD rules would match new packets from WAN to LAN/WLAN - these packets would go through the default ACCEPT policy. The return packets though will match and pass through the first rule being in the state of "RELATED,ESTABLISHED".

This is what I believe is the problem: bad guys from the WAN side could use the WAN IP address as a gateway to connect to any internal LAN/WLAN side devices so long as they have your internal IP addresses. But guessing that should be a no-brainer as 192.168.1.0/24 is the default, and a brute force port scan shouldn't be too hard to discover internal IPs too.

[RMerlin]

I admit it's been a long time since I've done any advanced iptables stuff, so my answer was a bit hasty, and indeed completely wrong (that rule matches natted packets, it does not jump to the nat table). Looking more closely at this, I still doubt that this would be an issue.

My theory is that, to hit a LAN device with an unroutable IP (such as 192.168.1.100), someone would have to be connected directly on your WAN port to submit the crafted packet with a source IP being his IP, and a target IP being the LAN target. Otherwise, such a packet would never even reach your device - your ISP can't route packets to you if they have a destination address that is a non-routable IP. The only packets routed to you have a destination IP that's your WAN IP (unless you actually have a routed block). That ends up on your router, at which point it will go through the whole iptable system to process the packet, forwarding it to a LAN PC only if there is a DNAT rule for it.

Caveat: someone with more advanced network knowledge could still prove me wrong - I admit to not being a networking engineer myself. If so, I'd be interested to read the correct explanation.

As an aside, I dug out a very informative flowchart showing how the various chains are related to one another in iptables:

http://www.linuxhomenetworking.com/w...0/Iptables.gif

EDIT: one scenario I just thought of where this could become an issue is if instead of fronting the Internet your router was fronting another private network segment. Then, it could become imaginable for someone to submit a packet with a non-routable IP directly to your router.

[ipaq]

Originally Posted by RMerlin

The only packets routed to you have a destination IP that's your WAN IP (unless you actually have a routed block).

EDIT: one scenario I just thought of where this could become an issue is if instead of fronting the Internet your router was fronting another private network segment. Then, it could become imaginable for someone to submit a packet with a non-routable IP directly to your router.

RMerlin, you are exactly right. The security risk for normal home users should be minimal. But incidentally both scenarios you described apply to me. I am buying this unit for my own office PC which has 2 NICs so that I can have my private WLAN to connect all my gadgets like mobile phone, laptop, printer, so on and so forth. I don't care much for this use case.

But If everything go well, I'd recommend it for use with my workplace's business broadband that has a small /29 network is routed via the WAN port. This could be a bigger issue here for business use. Who knows what's on the same WAN segment? There could be attackers from other companies or the broadband company itself.

Anyways, perhaps I am a bit too paranoid and over cautious about network security. But I still think it is a good idea to restrict WLAN->LAN/WLAN forwarding like I first described if the "Firewall" setting is on. It's a accidental and surprise find because I was doing some benchmarking due to its lower than expected transfer rate. But an unsuspecting person or business might not be aware of the fact that turning the firewall on still has serious leaks.

[miccos]

Originally Posted by ipaq

RMerlin, you are exactly right. The security risk for normal home users should be minimal.

Actually, if I am reading this thread right, this vulnerability situation is actually common. Many housing organizations around here have internal networks between the apartments to facilitate direct communication, often between several buildings of the same owner. These internal networks were often constructed with simple switches due to costs (back in the day).

The inhabitants of the apartments then use PPPoE to connect to the internet through the internet providers gateway/router residing in the network. So the bad news is that basically any neighbour can be directly connected to the others WAN ports and could be trying to send malicious packets behind the other's firewall!