Asus RT-N56U Reviewed

[Unregistered]

How do you disable hardware NAT on this router?

 

[Starrbuck]

If it is hardware or software is actually irrelevant.

Depends on what your considerations are. Hardware NAT is more efficient than software NAT. However, if it breaks functionality that you need, you may have to give up that efficiency. That seems to be the case with this router today.

 

[Starrbuck]

How do you disable hardware NAT on this router?

Basically if you enable any of the QoS features or the VPN passthru abilities it will disable the hardware NAT. You can verify by going to the System Log >> Port Forwarding where it will show you if it is enabled or disabled.

 

[Shikami]

Depends on what your considerations are. Hardware NAT is more efficient than software NAT. However, if it breaks functionality that you need, you may have to give up that efficiency. That seems to be the case with this router today.

NAT is NAT, and to note there is no standard to NAT. So it may vary from device to device, operating system, etc. Although, there are some what defacto's when it come to types of NAT. The only difference to hardware and software NAT is like how 3D rendering used to be software and now it is accelerated by the GPU's. Hardware usually means a dedicated unit that offloads the tasks, but does not necessitate efficiency because of such. Architectural differences and changes to a CPU can make even software NAT run more efficiently than hardware NAT devices.

Of course NAT breaks VPN functionality, and to not know this means that there is some ignorance of this particular subject matter. It is as I just explained before. The end points do not have connectivity with each other as NAT prevents this from happening since you are privately behind the public domain, inadvertently. In other words many will say for a marketing point that NAT is a security feature, NAT is not as so; and was never meant to be.

Basically if you enable any of the QoS features or the VPN passthru abilities it will disable the hardware NAT.

Just to be clear L2TP, IPsec will disable HW NAT, but not PPTP. Enabling multicasting and QoS will also disable HW NAT.

 

[RogerSC]

This sort of implies that if you are using VPN passthrough that software NAT cannot be turned on for those connections? Is that really true? It might be, just thought I'd ask *smile*.

 

[Shikami]

This sort of implies that if you are using VPN passthrough that software NAT cannot be turned on for those connections?

When the HW NAT is disabled the 500MHz RISC core will process the NAT rules, tables, et al. So, it will be in "software." The packets will not be offloaded by the HW NAT coprocessor. I think that is your question?

 

[Starrbuck]

NAT is NAT.

I disagree, because if hardware NAT wasn't "better" than software NAT, ASUS and other manufacturers who have it would not use it as a selling point. I am no NAT expert as you appear to be, so I'll leave that to you. This is just my opinion.

Just to be clear L2TP, IPsec will disable HW NAT, but not PPTP. Enabling multicasting and QoS will also disable HW NAT.

Thanks for clarifying. This is why I suggested the way to check it by looking in the logs.

 

[Starrbuck]

This sort of implies that if you are using VPN passthrough that software NAT cannot be turned on for those connections? Is that really true?

It's an all-or-nothing deal. You unfortunately can't use hardware for some connections and software for other connections. Once you disable hardware NAT, all connections will be using software NAT.

 

[Shikami]

I disagree, because if hardware NAT wasn't "better" than software NAT, ASUS and other manufacturers who have it would not use it as a selling point.

I did not say it was not better, and I should advise caveat emptor; do not easily get caught up by marketing ploys. NAT is NAT, this is true. What you are not looking into to gain the better ascertained advantage is knowledge of core logics. It is true that in this situation the coprocessor provides an advantage, as it can with many other examples. However, not all the time will it be so. Because as the coprocessor is just a specialized processor for NAT only in this case, you can make a specialized processor that is better than the coprocessor and everything else. It is simple engineering and happens all the time.

You said "hardware NAT is more efficient." Efficiency, comes in many ways; and in certain cases the ability of one hardware example can surpass the other when it used not to. Think of how the processor(s) still handles much of the networking stack's tasks with a Windows or Linux system, but some, or even more tasks of the networking stack are offloaded to the NIC. Such as offloading the checksum and the segmentation of the packets are very common with NIC's now-a-days. However, if you disabled this you may not notice the difference as much as you think, as long as you have a capable processor. Basically as tasks are increased for the system, or if the processor is a bottleneck, offloading can benefit the system/device much.

Do you see what I am trying to explain? The hardware changes from time to time; and places the burden in hardware then to software as other hardware improves. To note, there are two things I love in computerdom: Buffers and offloading .

 

[Starrbuck]

From the Asus website:

"Gigabit Internet Surfing with Hardware NAT

Equipped with a capable hardware NAT acceleration engine and built-in Gigabit Ethernet, it gives you full Gigabit internet performance, making its WAN to LAN throughput up to 2-5 times that of traditional software-based NAT Gigabit routers."

The marketing hype says their hardware NAT gives 2-5x greater throughput than software NAT. You should keep the hardware NAT enabled (if you can) for greater throughput (and if you care about throughput). Those are the only points I am trying to make. If you have some benchmarks to the contrary, I'd love to see them.

 

[Shikami]

Those are the only points I am trying to make. If you have some benchmarks to the contrary, I'd love to see them.

You are not comprehending a single word that I have written.

 

[RogerSC]

Yes, I did some research on NAT and VPN from the standpoint of my work's Cisco VPN, and found that NAT is used with the VPN by using the IPSec passthrough feature where the IPSec packets are encapsulated in UDP packets (my connection uses UDP). So NAT can be used by leaving the IPSec packets intact, header and all inside of a UDP packet. That seems to be how the VPN that I'm using works.

This doesn't however, answer the question of why the rt-n56u's hardware NAT is not compatible with a VPN like Cisco's. Is that a matter of time until Asus gets this right, or will it always be a matter of turning off hardware NAT to use a Cisco VPN? Time will tell.

I do understand, by the way, that when hardware NAT is turned off, the router falls back to software NAT.

I'm willing to wait, my current router works okay, and the longer I wait the more chance that a newer router will come out that does this right and has hardware NAT *smile*.

 

[pidge]

Yes, I did some research on NAT and VPN from the standpoint of my work's Cisco VPN, and found that NAT is used with the VPN by using the IPSec passthrough feature where the IPSec packets are encapsulated in UDP packets (my connection uses UDP). So NAT can be used by leaving the IPSec packets intact, header and all inside of a UDP packet. That seems to be how the VPN that I'm using works.

This doesn't however, answer the question of why the rt-n56u's hardware NAT is not compatible with a VPN like Cisco's. Is that a matter of time until Asus gets this right, or will it always be a matter of turning off hardware NAT to use a Cisco VPN? Time will tell.

I do understand, by the way, that when hardware NAT is turned off, the router falls back to software NAT.

I'm willing to wait, my current router works okay, and the longer I wait the more chance that a newer router will come out that does this right and has hardware NAT *smile*.

I could be wrong but I believe previous firmware version supported Cisco VPN. It was only the recent few firmwares have problem with Cisco VPN when hardware NAT is enabled.

 

[Starrbuck]

You are not comprehending a single word that I have written.

Perhaps that is because they are incomprehensible.

 

[foxyloxy]

My printing also gave up with 1.0.1.4m - did you fix it?

Can you guys still access your USB printer over the network after upgrading to 1.0.1.4m?

 

[RogerSC]

I could be wrong but I believe previous firmware version supported Cisco VPN. It was only the recent few firmwares have problem with Cisco VPN when hardware NAT is enabled.

Okay, so what is the latest firmware revision that the Cisco VPN work with without disabling hardware NAT?

That would be very helpful to hear, then I can make a judgement of whether I want to go that way.

 

[Shikami]

Yes, I did some research on NAT and VPN from the standpoint of my work's Cisco VPN, and found that NAT is used with the VPN by using the IPSec passthrough feature where the IPSec packets are encapsulated in UDP packets (my connection uses UDP). So NAT can be used by leaving the IPSec packets intact, header and all inside of a UDP packet. That seems to be how the VPN that I'm using works.

Well, since NAT is in use and VPN is being used to transmit encapsulated/encrypted data, you will need a passthrough technique. You do not have a true end point because of NAT segregating you from the "public" network (Internet). So, something has to be done in understanding what to do with this datagram, especially since any mangling of it will cause the VPN to fail; and this is what NAT does. Re-writing the header of the packet that was public and turning it into a header for the private network (behind the router) every time the packets come in and also when the packets are transmitted or they will not route to any public network. Except when they are private network they will not be overwritten.

This doesn't however, answer the question of why the rt-n56u's hardware NAT is not compatible with a VPN like Cisco's. Is that a matter of time until Asus gets this right, or will it always be a matter of turning off hardware NAT to use a Cisco VPN? Time will tell.

Because, it is a Linux iptables firewall, and Asus has created the rules for how the firewall will interpret the communications received and transmitted. Technically speaking there should be no issue. It seems that Ralink could make the driver not touch these packets/datagrams and pass them through without offloading if that causes a problem; or at least iptables handle the TX/RX properly. I am unsure what is the problem: coprocessor or iptables. I do know that there have been some clean ups (according to Egger's web site) of the iptables, and along with reports of you (plural) saying your VPN's working or not.

I do understand, by the way, that when hardware NAT is turned off, the router falls back to software NAT.

Well, technically speaking it is always done in software with hardware, but there is a coprocessor in the RT3662 that offloads the NAT processing from the RISC core. Many say hardware and software without the careful understanding of semantics. It really is better to say that it offloads, which would mean that there is a specialty hardware unit for processing NAT. But I think we all understand what they and others mean when they say "hardware NAT." Because, if the offloading was disabled the RISC core would handle the work. This is still hardware since it is a CPU, but requires more cycles to process than the coprocessor does for NAT. This is similar to how many instructions are added to a processor to reduce the work done.

 

[JMPATLANTA]

Returning Asus

I ordered and trialed this thing for a week and just couldn't fall in love with it. I think Asus still has more work to do on this 56 model with firmware before it can be given as good a review at least from my point of view. Below are some of the caveats that I think ruins this device at least for my use.
1) DHCP - limit of 8 reservations
2) Hardware NAT - may be good for folks not needing/using different VPN technologies but the fact that HW NAT has to be pretty much disabled to be able to use IPSec clients such as Cisco, etc. is a killer for me.
3) Router seems to hang transmission-wise fairly often. You don't lose socket, the data just seems to stall for a little while then resumes.
4) Wireless coverage compared to my DIR-655 is much better but issue 3 above kills the benefit.
5) Odd naming of Port Forwarding to Virtual Server is odd.
6) Inability to allow ISP DNS Servers to pass through to router's DHCP Server assigned IP addresses is silly to be missing. I think a lot of the Web Page pausing found when opening web pages through this device is due to it's DNS caching/serving client.

I think this would be a great router if Asus get's the bugs fixed with the firmware but I can't wait for them to do it and who knows if they even can enable VPN IPSec support over hardware NAT on this device. So now, I am going back to my trusty Dlink DIR-655 rev.A4 and currently ordering hopefully a DIR-655 Rev. B that I will receive tomorrow.

 

[Starrbuck]

1) DHCP - limit of 8 reservations

As I noted in an earlier post, with firmware > 1.0.1.3 the limit is greater than 8, possibly 16. I had 15 specified and working correctly with 1.0.1.4m.

I agree that the router still needs some work to be great. I have gone back to my trusty Linksys E4200 for now.

 

[JMPATLANTA]

As I noted in an earlier post, with firmware > 1.0.1.3 the limit is greater than 8, possibly 16. I had 15 specified and working correctly with 1.0.1.4m.

I agree that the router still needs some work to be great. I have gone back to my trusty Linksys E4200 for now.

Yeah, the only thing is that my gut tells me that the firmware developers for this may not be as seasoned as older device manufactuers like Linksys/Cisco, D-link, etc. which was the primary reason for me returning the router. Do they have a promising future, I think so but I can't wait. I will probably re-visit Asus later on after I see better reports of stability but for now I gotta stick with what works as my livelihood is at stake.