IPSEC and IOS

[Odkrys]

Which GPL version are you checking? That code didn't seem to be commented out in 384_20379 (the latest I've got).

20287.

https://github.com/blackfuel/asuswrt-gt-ac5300/blob/master/release/src/router/rc/services.c

 

[RMerlin]

Thanks. Looks like for some reason that didn't get merged into my own repo.

And meanwhile I fixed the RT-AC86U build of IPSEC - the precompiled libssl/libcrypto Asus provided in the GPL were compiled with -no-engine, preventing it from loading. I recompiled them, and now my Zenpad is able to succesfully connect to the RT-AC86U.

 

[Odkrys]

Thanks. Looks like for some reason that didn't get merged into my own repo.

And meanwhile I fixed the RT-AC86U build of IPSEC - the precompiled libssl/libcrypto Asus provided in the GPL were compiled with -no-engine, preventing it from loading. I recompiled them, and now my Zenpad is able to succesfully connect to the RT-AC86U.

In my experience, no-engine made some conflicts with wget and openvpn when I built from your clean repo. (need a test)
So I commented out 2lines in /strongswan-5.2.1/src/libstrongswan/plugins/openssl/openssl_plugin.c.

	//ENGINE_load_builtin_engines();
	//ENGINE_register_all_complete();

And now TOR and IPSec both work fine without no-engine option.
But maybe there be a potential risk.

 

[RMerlin]

In my experience, no-engine made some conflicts with wget and openvpn when I built from your clean repo. (need a test)
So I commented out 2lines in /strongswan-5.2.1/src/libstrongswan/plugins/openssl/openssl_plugin.c.

    //ENGINE_load_builtin_engines();
    //ENGINE_register_all_complete();

And now TOR and IPSec both work fine.
But maybe there be a potential risk.

I simply recompiled the aarch64 version of OpenSSL with engine support enabled, so no code change was necessary. The updated static builds are now on Github. My Zenpad was able to access my RT-AC86U's webui from its LAN address while connected through IPSEC, so IPSEC is definitely working fine now on that model.

The regular 32-bit build of OpenSSL always had engine support enabled (as it's necessary for Tor and probably others as well). I haven't changed anything, so OpenVPN/Tor shouldn't be unaffected.

 

[Odkrys]

I simply recompiled the aarch64 version of OpenSSL with engine support enabled, so no code change was necessary. The updated static builds are now on Github. My Zenpad was able to access my RT-AC86U's webui from its LAN address while connected through IPSEC, so IPSEC is definitely working fine now on that model.

The regular 32-bit build of OpenSSL always had engine support enabled (as it's necessary for Tor and probably others as well). I haven't changed anything, so OpenVPN/Tor shouldn't be unaffected.

Ah ok, I will build with new libcrypto and libssl.
BTW, don't you have system log problem ? It is happening only to me?

 

[RMerlin]

BTW, don't you have system log problem ? It is happening only to me?

I don't understand what you mean by this, sorry.

 

[Odkrys]

I don't understand what you mean by this, sorry.

Clear system log and try signature update (or whatever makes syslog).
It appear like this.

Feb 19 16:12:54 rc_service: httpd 790:notify_rc start_sig_check
Feb 19 16:14:21 rc_service: httpd 790:notify_rc start_sig_check
Feb 19 16:12:54 rc_service: httpd 790:notify_rc start_sig_check
Feb 19 16:14:21 rc_service: httpd 790:notify_rc start_sig_check

 

[RMerlin]

Clear system log and try signature update (or whatever makes syslog).
It appear like this.

Feb 19 16:12:54 rc_service: httpd 790:notify_rc start_sig_check
Feb 19 16:14:21 rc_service: httpd 790:notify_rc start_sig_check
Feb 19 16:12:54 rc_service: httpd 790:notify_rc start_sig_check
Feb 19 16:14:21 rc_service: httpd 790:notify_rc start_sig_check

Doubt it's related to IPSEC. /tmp/syslog.log only contains the data once, so that'd be a display issue tied to either httpd or the webui, possibly triggered when clearing the logfile.

 

[Odkrys]

My Zenpad was able to access my RT-AC86U's webui from its LAN address while connected through IPSEC, so IPSEC is definitely working fine now on that model.

I could access the web ui when I connected another wi-fi (IPv4, different IP) but when I was using LTE (IPv6) web ui didn't response. (internet was ok)
maybe somewhere related ipv6 seems be broken.

Doubt it's related to IPSEC. /tmp/syslog.log only contains the data once, so that'd be a display issue tied to either httpd or the webui, possibly triggered when clearing the logfile.

I hope to be fixed. I couldn't find wrong point.

 

[RMerlin]

Found it. It's a bug in httpd that only appears when IPSEC support is enabled, there should be an "else if" instead of an "if" there:

https://github.com/RMerl/asuswrt-merlin.ng/blob/master/release/src/router/httpd/web.c#L1649

Otherwise, it causes the requested logfile to be sent twice. Probably breaks various other system dump calls in that same function as well.

 

[Odkrys]

Found it. It's a bug in httpd that only appears when IPSEC support is enabled, there should be an "else if" instead of an "if" there:

https://github.com/RMerl/asuswrt-merlin.ng/blob/master/release/src/router/httpd/web.c#L1649

Otherwise, it causes the requested logfile to be sent twice. Probably breaks various other system dump calls in that same function as well.

Now log seems normal, thanks.

 

[RMerlin]

I ran some iperf benchmarks through the RT-AC86U running IPSEC. Results here:

https://www.snbforums.com/threads/openvpn-performance-of-the-rt-ac86u.41217/page-6#post-383278

 

[XIII]

Wow, even the iOS feature "VPN On Demand" works with IPsec on the RT-AC86U. Super neat!

http://www.loxwiki.eu/display/LOX/VPN+on-demand

 

[Robin]

Unsure about special characters, but generally asuswrt is very fragile to these, best to avoid using them when in doubt.

I stumbled across this thread having exactly the same problem. It turns out the solution was to remove the spaces from my pre-shared key. Works like a dream now. You weren't kidding about "fragile"!