SmallNetBuilder Forums
Go Back   SmallNetBuilder Forums > Wireless Networking > ASUS Wireless > ASUS N Routers & Adapters

Reply
 
Thread Tools Search this Thread Display Modes
  #1  
Old 11-08-2012, 07:41 AM
ipaq ipaq is offline
New Member
 
Join Date: Nov 2012
Posts: 3
Thanks: 0
Thanked 0 Times in 0 Posts
ipaq is just starting out
Default WAN-LAN throughput & firewall issues

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:

Quote:
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?

Quote:
iptables -P FORWARD DROP
iptables -D FORWARD ! -i br0 -o eth0 -j DROP
iptables -I FORWARD -i br0 -o eth0 -j ACCEPT
Reply With Quote
  #2  
Old 11-08-2012, 12:39 PM
RMerlin's Avatar
RMerlin RMerlin is online now
Very Senior Member
 
Join Date: Apr 2012
Location: Canada
Posts: 10,343
Thanks: 54
Thanked 5,779 Times in 2,359 Posts
RMerlin is just starting out
Default

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

Quote:
0 0 ACCEPT all -- any any anywhere anywhere ctstate DNAT
So you should never have unmodified packets forwarded by the default rule.
__________________
Asuswrt-Merlin: Customized firmware for Asus routers
Github: github.com/RMerl - Twitter: RMerlinDev
See the sticky post for more info.

Last edited by RMerlin; 11-08-2012 at 12:42 PM.
Reply With Quote
  #3  
Old 11-08-2012, 09:18 PM
ipaq ipaq is offline
New Member
 
Join Date: Nov 2012
Posts: 3
Thanks: 0
Thanked 0 Times in 0 Posts
ipaq is just starting out
Default

RMerlin,

Quote:
Originally Posted by RMerlin View Post
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.
Reply With Quote
  #4  
Old 11-09-2012, 12:34 AM
RMerlin's Avatar
RMerlin RMerlin is online now
Very Senior Member
 
Join Date: Apr 2012
Location: Canada
Posts: 10,343
Thanks: 54
Thanked 5,779 Times in 2,359 Posts
RMerlin is just starting out
Default

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.
__________________
Asuswrt-Merlin: Customized firmware for Asus routers
Github: github.com/RMerl - Twitter: RMerlinDev
See the sticky post for more info.

Last edited by RMerlin; 11-09-2012 at 12:45 AM.
Reply With Quote
  #5  
Old 11-09-2012, 08:48 AM
ipaq ipaq is offline
New Member
 
Join Date: Nov 2012
Posts: 3
Thanks: 0
Thanked 0 Times in 0 Posts
ipaq is just starting out
Default

Quote:
Originally Posted by RMerlin View Post
The only packets routed to you have a destination IP that's your WAN IP (unless you actually have a routed block).
Quote:
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.
Reply With Quote
  #6  
Old 11-16-2012, 09:50 PM
miccos miccos is offline
New Member
 
Join Date: Nov 2012
Posts: 4
Thanks: 0
Thanked 0 Times in 0 Posts
miccos is just starting out
Default

Quote:
Originally Posted by ipaq View Post
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!
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off


All times are GMT -4. The time now is 09:42 AM.


Top 10 Stats
Top Posters* Top Thanked
RMerlin  371
john9527  145
stevech  136
azazel1024  129
hggomes  89
noric  81
sfx2000  76
L&LD  70
fistv  63
TonyH  62
RMerlin  5778
stevech  336
john9527  281
ryzhov_al  272
TeHashX  228
L&LD  204
RogerSC  195
sinshiva  146
joegreat  127
sfx2000  124
Most Viewed Threads* Hottest Threads*
Old Asuswrt-Merli...  12531
Old Asuswrt-Merli...  9856
Old My...  5334
Old Most stable...  4259
Old Asuswrt-Merli...  4192
Old Thinking of...  3900
Old RT-AC87R (U)...  3804
Old Connection...  3198
Old [HOW TO]...  2921
Old Can't trust...  2391
Old Asuswrt-Merli...  122
Old Asuswrt-Merli...  59
Old Connection...  59
Old My...  56
Old [HOW TO]...  50
Old RT-AC87R (U)...  39
Old USB N...  31
Old Most stable...  29
Old New...  28
Old Second new...  27


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
© 2006-2014 Pudai LLC All Rights Reserved.