Mysterious semi-bricking

[kfmfe04]

Last night, I installed Merlin's:

RT-N66U_3.0.0.4_270.24.trx

and tried following the instructions here to work openVPN:

http://blog.bertelsen.co/2013/04/asus-rt-n66u-with-openvpn-server.html

I messed up somewhere and got the N66U into a very odd state.
If I physically disconnect the ethernet cable to the ADSL modem while rebooting, I can access the router via the web-interface and ssh (damn, I love having ssh access to the router!). But once I connect the ethernet cable to the WAN, I can no longer access the router (in fact, I can't even ping it). The odd thing is, all indicator lights on the router look ok, including connection to the WAN.

The only way I can "recover" is to reboot, disconnect the WAN, and reinstall Asus' FW, and reconnect the WAN:

RT-N66U_3.0.0.4_270.trx

I tried again with the newer Merlin build:

RT-N66U_3.0.0.4_270.26b.trx

but I had the same problem - whenever the WAN cable was connected, the router would brick. So I've reverted back to the ASUS FW for now.

I suspect I must've screwed up the settings somehow (in openVPN?!?) and those settings are being retained as I do various upgrades/downgrades. But oddly enough, those settings are killing me in the Merlin installs with WAN connected only.

I'm looking for a way to clear my settings so I can retry Merlin's:

RT-N66U_3.0.0.4_270.26b.trx

again. Any suggestions and/or insights would be greatly appreciated!

 

[RMerlin]

The OpenVPN service is probably hosing networking when it starts. Try booting with the WAN unplugged. Go to the OpenVPN pages, and make sure that all instances are set `Start with WAN = no`, and also stop any running instances. Save the changes, then reconnect your WAN cable. After that you can recheck your OpenVPN settings to determine what went wrong.

 

[kfmfe04]

The OpenVPN service is probably hosing networking when it starts. Try booting with the WAN unplugged. Go to the OpenVPN pages, and make sure that all instances are set `Start with WAN = no`, and also stop any running instances. Save the changes, then reconnect your WAN cable. After that you can recheck your OpenVPN settings to determine what went wrong.

Thanks for the tips! I will try again right now.

FWIW, I live in Taipei (about 30min from ASUS's main HQ in Beitou - I don't know where their Router R&D is located, though) - maybe one of these days, I can sneak in and talk to their router guys.

Oh, and my undergrad major from years ago was EE, but I've been purely a software guy the last few decades - when I get this working, I will download your code via git and take a look for fun (I primarily do C++ these days)...

WTF - I just chatted with my uncle - apparently, he was classmates with some of the founders of ASUS/BenQ, so maybe I can sneak in there after all. Anyhow, I will get back to the reinstall and repost.

 

[kfmfe04]

FANTASTIC - `Start with WAN = no` unbricked the unit.

The part that surprised me was that the setting had an effect even though Server State was OFF and VPN status showed that no daemons were running.

Thank you so much.

BTW, can you briefly explain why there is a VPN Server1 and Server2? (as opposed to the standard model with one daemon that spawns to service a new client)

I apologize in advance if I am asking a really basic question.

 

[RMerlin]

FANTASTIC - `Start with WAN = no` unbricked the unit.

The part that surprised me was that the setting had an effect even though Server State was OFF and VPN status showed that no daemons were running.

Thank you so much.

BTW, can you briefly explain why there is a VPN Server1 and Server2? (as opposed to the standard model with one daemon that spawns to service a new client)

I apologize in advance if I am asking a really basic question.

Server State is the current state. If you have it set to start with WAN, then the state will turn to "On" after WAN is started and the server also gets started. It's also what lets you manually start or stop it without having it set to start automatically with WAN. Essentially it's not a setting, but a toggle switch (hence the different visual).

The two distinct servers aren't to accommodate multiple clients (each server can service multiple clients just fine), but to accommodate two different configurations. For example, Server1 could be TUN-based on port 1194, but Server2 would be TAP-based on port 1195. Depending on the port your client use, it would connect either to the first, or the second server instance, with the different settings.

 

[RMerlin]

WTF - I just chatted with my uncle - apparently, he was classmates with some of the founders of ASUS/BenQ, so maybe I can sneak in there after all. Anyhow, I will get back to the reinstall and repost.

Try to sneak out with some prototypes for us

 

[kfmfe04]

Thanks for the quick reply (I suspect the different configuration per server when I thought about it some more - the Start with WAN thing was unexpected, but perfectly explains the router's behavior now).

After playing some more, I understand how I bricked the unit now - but am unsure how to coax the router to do what I want.

Background:

When I tried PPTP a few days ago, I followed your suggestion in one of your threads - segment the subnet into 3 parts: manual, DNS, and VPN - this worked perfectly for me so I tried to do the same thing here for OpenVPN.

My intranet is 192.168.11.X so for OpenVPN, I typed in 192.168.11.0, 255.255.255.0 in place of 10.8.0.0, 255.255.255.0 that was in that tutorial. Now that I have returned the setting back to 10.8.0.0, all signs of bricking have disappeared.

My next steps:
1. Get openVPN working with 10.8.0.0 first
2. Figure out how to use the same subnet as the intranet (192.168.11.X)

Trek to Asus:
I am hoping that if I can get to talking with the R&D guys, I can have them incorporate your changes into their code base more easily/quickly (provided that's ok with you - I haven't seen your licensing yet) and/or perhaps impact their firmware development in positive ways.

But, one step at a time - I will post in a new thread if I manage to "get in".

 

[RMerlin]

When I tried PPTP a few days ago, I followed your suggestion in one of your threads - segment the subnet into 3 parts: manual, DNS, and VPN - this worked perfectly for me so I tried to do the same thing here for OpenVPN.

My intranet is 192.168.11.X so for OpenVPN, I typed in 192.168.11.0, 255.255.255.0 in place of 10.8.0.0, 255.255.255.0 that was in that tutorial. Now that I have returned the setting back to 10.8.0.0, all signs of bricking have disappeared.

My next steps:
1. Get openVPN working with 10.8.0.0 first
2. Figure out how to use the same subnet as the intranet (192.168.11.X)

That isn't needed with OpenVPN. The OpeNVPN client adds a static route on the client computer, so you will be able to reach your LAN clients despite being in a different subnet. You just need to ensure that your LAN still has a different subnet than your remote network from where you are connecting (i.e. your work network).

This is a much cleaner solution than PPTP.

Trek to Asus:
I am hoping that if I can get to talking with the R&D guys, I can have them incorporate your changes into their code base more easily/quickly (provided that's ok with you - I haven't seen your licensing yet) and/or perhaps impact their firmware development in positive ways.

While I am not in direct contact with the devs, I am in regular contact with someone at Asus who is directly in contact with them. They are aware of this project, and have even integrated some of its code in the past (like the WPS radio toggle button) or some patches that I have submitted to them (mostly bug fixes). They re-implemented WOL themselves probably because the implementation I did was very poorly integrated (it was the very first thing I wrote for this FW, back when I barely understood the code).

They are being very cautious as to what feature they implement because of having different priorities. As manufacturers of a mass-market device, any feature that gets implemented is a feature they will have to officially provide support for. Therefore they have to be more conservative as to what feature they implement. OpenVPN for example is a great feature, but providing technical support for it could become expensive to them, and not be worth it for a 100-150$ product. That's one of the reasons why more expensive products offer more features - not just to differentiate products, but also to cover the added cost increases in after-sale technical support.

Everything I do is under GPL like the rest of the (non-proprietary) firmware, so anyone is welcome to reuse it.