Asuswrt-Merlin 378.54_2 is now available

[MichaelR64]

I am having problems with OpenVPN on my AC87.
I had a N66 with OpenVPN on it and used Tunnelblick to connect to it from my Mac.
Changed to AC87 this weekend.
Apart from the fact that the mac connect speeds are not what i had hoped for i can not get the Tunnelblick client to connect to the ac87.
My android phone does connect so the openvpn server is working and accessable but something is different though.

I am not running any extra dlna stuff, neither do i have any usb things attached to it.
I use the this router, just as the n66 before it, for its good wireless range and ability to have openvpn on it.

Tunnelblick keeps trying to connect.
Tunnelblick has these logs available:

*edited fro brevity

I edited out my dns name and ipadress it resolves to.
I also clipped the rest since it just keeps looping.

I am hoping someone knows whats wrong here.
Just to be clear: i've gotten openvpn and tunnelblick working in the past (n66).
Also openvpn on ac87 together with android works.

I looked some more here:
https://groups.google.com/forum/#!topic/tunnelblick-discuss/V657umITS5w
and someone on the google support group of tunnelblick says this needs to be fixed at the RMerlin side.

I looked at the changelog noted there: https://github.com/RMerl/asuswrt-merlin/blob/master/release/src/router/openssl/CHANGES
and noticed the fixes are in but dated a day after the 54_2 release.
Is it safe to say that this fix is not in the current build ?
If so when will they be in ?
I know when i use Shimo it works but probably because they use older keys ?

Perhaps RMerlin can shed some light here ?

 

[RMerlin]

I looked some more here:
https://groups.google.com/forum/#!topic/tunnelblick-discuss/V657umITS5w
and someone on the google support group of tunnelblick says this needs to be fixed at the RMerlin side.
Perhaps RMerlin can shed some light here ?
I forgot to say that when i use Shimo(openvpn client) it works.

There's absolutely nothing for me to fix there. That someone is just providing some random answers.

If you need a 1024-bit DH, you can manually generate one, and paste it on the Keys and Certificates page in place of the 512-bit one it has automatically created.

 

[MichaelR64]

As i said i also noticed the openssl fixes you made are checked in one day after the build date of the 54_2 build.
When do you plan to implement these in the fw ?
It seems that when you use Tunnelblick out of the box with the current version it uses 768bit DH because whereas the current fw of OpenVPN uses 512bit as you state.
I figured that if the next fw build would include the openssl changes it would generate this automatically since you state this in the changelog:

*) Reject DH handshakes with parameters shorter than 768 bits.
[Kurt Roeckx and Emilia Kasper]

That sort of implies to me that it would also generate 768bit or longer DH without the user explictly telling the router to do so.
Ofcourse with the limited knowledge i have of ssl etc.
All of this because of the Logjam ssl attack .

 

[RMerlin]

As i said i also noticed the openssl fixes you made are checked in one day after the build date of the 54_2 build.
When do you plan to implement these in the fw ?

When 378.55 is released, which won't be for at least a few weeks, as the current Asus GPL code has numerous issues.

It seems that when you use Tunnelblick out of the box with the current version it uses 768bit DH because whereas the current fw of OpenVPN uses 512bit as you state.
I figured that if the next fw build would include the openssl changes it would generate this automatically since you state this in the changelog:

It currently doesn't. You have to manually regenerate it yourself. I haven't worked out a plan on how to handle this yet either.

That sort of implies to me that it would also generate 768bit or longer DH without the user explictly telling the router to do so.

Only on a first-time setup, or if you were to delete the existing DH (which is more tricky with 378.55, since the existing ones are no longer visible on the webui since they are moved to the JFFS partition).

It's all in early development, hence I won't have anything ready for release for weeks.

In the meantime as I said, simply generate a new DH, and paste it on the DH field of your router to replace it. The OpenSSL version you use does not matter, you don't need the newer version to do this.

openssl dhparam -out dh.pem 1024
cat dh.pem

 

[JohnNerd]

Dear Merlin,

Please help! I've got an AC66U in Media Bridge Mode and against an AC87U. It is very unstable. I get connections now and then, but media/internett would freeze and reconnect all the time, sometimes not connect at all.
I've hard reset both routers after FW upgrade.
Tried NAT, and other settings. Including disabling 2.4G
I got a lot of these messages:
"kernel: eth2: received packet with own address as source address".
I've also tried other FW versions including 378.54_2
Repeater modus iis working better, but still very, very unstable.

Thank you so much for your hard work!!!

JohnNerd

 

[sbailey4]

Dear Merlin,

Please help! I've got an AC66U in Media Bridge Mode and against an AC87U. It is very unstable. I get connections now and then, but media/internett would freeze and reconnect all the time, sometimes not connect at all.
I've hard reset both routers after FW upgrade.
Tried NAT, and other settings. Including disabling 2.4G
I got a lot of these messages:
"kernel: eth2: received packet with own address as source address".
I've also tried other FW versions including 378.54_2
Repeater modus iis working better, but still very, very unstable.

Thank you so much for your hard work!!!

JohnNerd

You said "hard reset", meaning a power off or have you cleared NVRAM? If not defaulted it after the firmware load I believe I would try that first. Perhaps Merlin will have further comments but a nvram clear/reset helps most times for instability especially if you never did it after the update from a previous version. Here is more info regarding that topic and procedure

 

[JohnNerd]

You said "hard reset", meaning a power off or have you cleared NVRAM? If not defaulted it after the firmware load I believe I would try that first. Perhaps Merlin will have further comments but a nvram clear/reset helps most times for instability especially if you never did it after the update from a previous version. Here is more info regarding that topic and procedure

Thank you for your effort, but I already tried this... No success.

 

[IAAI]

God damn it , been getting these in logs every hour (Tried adding "tls-version-min 1.0" with no luck)

2:52 openvpn[934]: TLS: soft reset sec=0 bytes=90*****4/0 pkts=1****6/0
2:52 openvpn[934]: VERIFY OK: depth=1, /C=US/ST=FL/L=Winter_Park/O=VPNCompany/OU=VPNCompany_VPN/CN=VPNCompany_CA/emailAddress=support@VPNCompany.com
2:52 openvpn[934]: VERIFY X5*****E OK: /C=US/ST=FL/L=Winter_Park/O=VPNCompany/OU=VPNCompany_VPN/CN=XXX-Z53.VPNCompany.com/emailAddress=support@VPNCompany.com
2:52 openvpn[934]: VERIFY OK: depth=0, /C=US/ST=FL/L=Winter_Park/O=VPNCompany/OU=VPNCompany_VPN/CN=XXX-Z53.VPNCompany.com/emailAddress=support@VPNCompany.com
2:52 openvpn[934]: Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
2:52 openvpn[934]: Data Channel Encrypt: Using 256 bit message hash 'SHA256' for HMAC authentication
2:52 openvpn[934]: Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
2:52 openvpn[934]: Data Channel Decrypt: Using 256 bit message hash 'SHA256' for HMAC authentication
2:52 openvpn[934]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA

 

[MichaelR64]

When 378.55 is released, which won't be for at least a few weeks, as the current Asus GPL code has numerous issues.



It currently doesn't. You have to manually regenerate it yourself. I haven't worked out a plan on how to handle this yet either.



Only on a first-time setup, or if you were to delete the existing DH (which is more tricky with 378.55, since the existing ones are no longer visible on the webui since they are moved to the JFFS partition).

It's all in early development, hence I won't have anything ready for release for weeks.

In the meantime as I said, simply generate a new DH, and paste it on the DH field of your router to replace it. The OpenSSL version you use does not matter, you don't need the newer version to do this.

openssl dhparam -out dh.pem 1024
cat dh.pem

Thank you merlin for your time.
In the meantime i got confirmation on this issue here: https://groups.google.com/forum/#!topic/tunnelblick-discuss/V657umITS5w that because of the logjam vulnerability the openssl suite and therefore the current Tunnelblick client requires 768bit keys.
I hope you find a way to incorporate this in future builds.

In the meantime thank you for your code.
I opened a terminal and pasted the code.
The output is this:

-----BEGIN DH PARAMETERS-----
MIGHAoGBANPZpUQa8I5UvjDOFC5PMaUIMfZJ4yskvW44jpk7NH0KM7niJ6lq05o2
NHsIc1IpM5JtwnqIGXap/MknPj+TjillkNTz5FUW7HLa9mz0uSf3ikFdMcIhtRat
u2OcwyvI/here are bits missing ofcourse..
-----END DH PARAMETERS-----

For others:
It took me some time to find this: but on the Advanced section of the vpn server there is a yellow link that allows you to specify in plain text the various keys.
Among that is the DH key i just generated.
Just paste it in there save it and bingo.

 

[jkbull]

There's absolutely nothing for me to fix there. That someone is just providing some random answers.

It might be wrong, but it wasn't a random answer. (I wrote it; I'm the Tunnelblick developer.)

I meant that the firmware needed to be "fixed" to (A) include the most recent OpenSSL to protect users from Logjam (but you've already committed that, you just haven't released it yet) and/or (B) generate larger keys. I was assuming the 512-bit DH keys came from Merlin in the first place, but that was just a guess (and still is).

If Merlin generates DH keys, it should probably generate 1024-bit or larger keys, since the OpenSSL team has announced that they will make 1024 the minimum key size in some future release and it would be nice not to have everything break then.

 

[Dalle]

I looked some more here:
https://groups.google.com/forum/#!topic/tunnelblick-discuss/V657umITS5w
and someone on the google support group of tunnelblick says this needs to be fixed at the RMerlin side.

I looked at the changelog noted there: https://github.com/RMerl/asuswrt-merlin/blob/master/release/src/router/openssl/CHANGES
and noticed the fixes are in but dated a day after the 54_2 release.
Is it safe to say that this fix is not in the current build ?
If so when will they be in ?
I know when i use Shimo it works but probably because they use older keys ?

Perhaps RMerlin can shed some light here ?

Same problem for me. I raised it in this thread:

http://www.snbforums.com/threads/as...-fails-diffie-helmann-dh-key-too-small.25326/

I will try the manual way as RMerlin suggests.

Best regards, Daniel

 

[cosmoxl]

God damn it , been getting these in logs every hour (Tried adding "tls-version-min 1.0" with no luck)

2:52 openvpn[934]: TLS: soft reset sec=0 bytes=90*****4/0 pkts=1****6/0
2:52 openvpn[934]: VERIFY OK: depth=1, /C=US/ST=FL/L=Winter_Park/O=VPNCompany/OU=VPNCompany_VPN/CN=VPNCompany_CA/emailAddress=support@VPNCompany.com
2:52 openvpn[934]: VERIFY X5*****E OK: /C=US/ST=FL/L=Winter_Park/O=VPNCompany/OU=VPNCompany_VPN/CN=XXX-Z53.VPNCompany.com/emailAddress=support@VPNCompany.com
2:52 openvpn[934]: VERIFY OK: depth=0, /C=US/ST=FL/L=Winter_Park/O=VPNCompany/OU=IPVanish_VPN/CN=XXX-Z53.VPNCompany.com/emailAddress=support@VPNCompany.com
2:52 openvpn[934]: Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
2:52 openvpn[934]: Data Channel Encrypt: Using 256 bit message hash 'SHA256' for HMAC authentication
2:52 openvpn[934]: Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
2:52 openvpn[934]: Data Channel Decrypt: Using 256 bit message hash 'SHA256' for HMAC authentication
2:52 openvpn[934]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA

this is working properly. renegotiating every hour is default and increases security.

 

[Raiu]

Installed. All default settings had to reboot router after 3 days. Check dhcp setting and this was set to normal. Also air play would not work with waking the Apple TV. Rolled back to 47 and my air play has come back between iPad and Apple TV also no reboots

 

[RMerlin]

It might be wrong, but it wasn't a random answer. (I wrote it; I'm the Tunnelblick developer.)

By random, I meant you took a guess as to what might be the issue, as you had no idea what the user's setup was, which led the user to believe that something was suddenly broken on my code, and that the only solution was a new software release. Sorry if you took it as a slight, that wasn't my intention.

I meant that the firmware needed to be "fixed" to (A) include the most recent OpenSSL to protect users from Logjam (but you've already committed that, you just haven't released it yet)

And also, I don't enable any of the export ciphers, so that limits the risks - that's why I didn't issue an emergency update with 1.0.2b (good thing I didn't either, cause 24 hours later here comes 1.0.2c... Sigh.)

and/or (B) generate larger keys. I was assuming the 512-bit DH keys came from Merlin in the first place, but that was just a guess (and still is).

The automated generation code was added by Asus, but the end-user can also provide their own DH - that was the instructions I provided to the original user. That's why I said there was nothing to fix really - the user can always (and actually probably should) generate their own DH.

If Merlin generates DH keys, it should probably generate 1024-bit or larger keys, since the OpenSSL team has announced that they will make 1024 the minimum key size in some future release and it would be nice not to have everything break then.

Already done, at the same time I updated to 1.0.2b:

https://github.com/RMerl/asuswrt-merlin/commit/f429d49a598542a03ff3234d7fdd2689c6e23342

This will be painful however, as generating a 1024-bit DH can take quite a few minutes on a router. This will be pretty bad on the older 600 MHz MIPS routers.

Personally, I disagree with the OpenSSL devs' decision to reject those weaker DHs. That should be up to the application (or the user configuring it) to decide, not to a library. This will break a lot of existing setups, some users being stuck with closed devices that does not let them provide their own DH, and the manufacturers will also never issue firmware upgrades for this. They will have no idea why suddenly their newer client will refuse to connect to their existing server/appliance.

IMHO, the job of the library is to provide with the functionalities, not to impose security decision on the application developers and the users.

 

[JohnNerd]

Can anyone help with my Media Bridge problem, please?

Thanks!

 

[MichaelR64]

Same problem for me. I raised it in this thread:

http://www.snbforums.com/threads/as...-fails-diffie-helmann-dh-key-too-small.25326/

I will try the manual way as RMerlin suggests.

Best regards, Daniel

Just do this as per RMerlins answer:



Open Terminal (osx windows is different , probably open a cmd window)
run this:

openssl dhparam -out dh.pem 1024
cat dh.pem

The output is this:

-----BEGIN DH PARAMETERS-----
MIGHAoGBANPZpUQa8I5UvjDOFC5PMaUIMfZJ4yskvW44jpk7NH0KM7niJ6lq05o2
NHsIc1IpM5JtwnqIGXap/MknPj+TjillkNTz5FUW7HLa9mz0uSf3ikFdMcIhtRat
u2OcwyvI/here are bits missing ofcourse..
-----END DH PARAMETERS-----

On the Advanced section of the VPN server there is a yellow link that allows you to specify in plain text the various keys.
It is called : "Content modification of Keys & Certification." next to Authorization Mode.

Among that is the DH key i just generated.
Just paste it in there save it and bingo.
No need to reexport the ovpn file.

 

[charlie2alpha]

Already done, at the same time I updated to 1.0.2b:

https://github.com/RMerl/asuswrt-merlin/commit/f429d49a598542a03ff3234d7fdd2689c6e23342

This will be painful however, as generating a 1024-bit DH can take quite a few minutes on a router. This will be pretty bad on the older 600 MHz MIPS routers.

Personally, I disagree with the OpenSSL devs' decision to reject those weaker DHs. That should be up to the application (or the user configuring it) to decide, not to a library. This will break a lot of existing setups, some users being stuck with closed devices that does not let them provide their own DH, and the manufacturers will also never issue firmware upgrades for this. They will have no idea why suddenly their newer client will refuse to connect to their existing server/appliance.

IMHO, the job of the library is to provide with the functionalities, not to impose security decision on the application developers and the users.

I fully agree and I already faced an issue because of this questionable decision, my mail server failed to relay anything for the last couple of days, when I checked the logs, what do you know, "dh key too small" was the constant error reported. My outbound relay provider has too weak keys. I informed them immediately but I doubt they will do much, I had to downgrade my system and block the OpenSSL upgrade altogether.

 

[Mike Dirnt]

Hi Merlin,

Media Server doesnt seem to detect video files completely from my WD my passport ultra through N66 after flashing to 378.54_2 firmware. I have done a reboot after flashing.

I have reverted back to 378.53_0 firmware. This firmware can load all of my files correctly.

 

[wojowojo16]

So....I looked at my router today and realized that in Port Forwarding I had 3 port forwards setup to my Tablo (Over The Air DVR) that I'm about 99% sure I didn't put there. With that said I have 3 ports that I DID set so the other group of 3 were very out of place. I MIGHT have put them in for the ooma and named them wrong but I checked the OOMA documenation and it says no port forwards are needed. Of course I deleted them and Tablo still worked so I didn't think much of it but I never checked to see the destination IP. I setup the Tablo to get a static IP via DHCP.

I have Port Triggering Turned off....so it didn't happen automatically. Is there ANY way other than me putting these ports in they could have gotten there? I am running this firmware.

FYI I keep a spreadsheet of all my macs, system names, IP's, what I assign manually, what I assign via dhcp, and my port forwards and thy were not listed there. Makes me think I didn't set them.

I know this post is kind of cryptic but this is the info I have.

 

[RMerlin]

So....I looked at my router today and realized that in Port Forwarding I had 3 port forwards setup to my Tablo (Over The Air DVR) that I'm about 99% sure I didn't put there. With that said I have 3 ports that I DID set so the other group of 3 were very out of place. I MIGHT have put them in for the ooma and named them wrong but I checked the OOMA documenation and it says no port forwards are needed. Of course I deleted them and Tablo still worked so I didn't think much of it but I never checked to see the destination IP. I setup the Tablo to get a static IP via DHCP.

I have Port Triggering Turned off....so it didn't happen automatically. Is there ANY way other than me putting these ports in they could have gotten there? I am running this firmware.

FYI I keep a spreadsheet of all my macs, system names, IP's, what I assign manually, what I assign via dhcp, and my port forwards and thy were not listed there. Makes me think I didn't set them.

I know this post is kind of cryptic but this is the info I have.

Where did you look? If it's on the Virtual Server page, then no, it had to be manually added by someone. If however it's on the Port Forward page, then check the last column (Chain). If it says VUPNP, then it means the port was automatically forwarded by your device through UPNP/NAT-PMP.