What's new

[Release] Asuswrt-Merlin 380.65 is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Last idea....instead of
pull-filter ignore "cipher"

try
pull-filter reject "cipher AES-256-GCM"
 
Why?
With pull-filter ignore "cipher" i can easily connect with blowfish, my problem is the HMAC error then ...
Or do you think, taht i can get rid of this error bei rejecting AES256?
 
@netguru , Can you tell us who your provider is? That information may help us help you. :)Thanks.
 
Here are my settings for policy rules for TogGuard. Port is tied to the cipher used. I had routing issues so I had to use Strict for Accept DNS Configuration and also use the dhcp-server DNS xxx.xxx.xxx.xx in Additional Config section which are the DNS servers of TorGuard.

edit: screen shot removed
 

Attachments

  • upload_2017-4-6_22-6-25.png
    upload_2017-4-6_22-6-25.png
    91.2 KB · Views: 688
Last edited:
I can' remember from reading the prior posts. But did you import the ovpn file from NVPN for the initial configuration?

I looked at your screen shot and compared it with Nord VPN instructions. You need to Change User Password Authorization to "Ja" or Yes (Unless you disabled it on purpose so your credentials would not appear on the post). Accept DNS to Strict, If using port 1194, then set encryption to AES-256-CBC. There is a one to one relationship between port and encryption cipher is my guess, just as there is with my provider. While you are it, make sure the certificates are there as well by clicking on Content modification of Keys & Certificates.
 
Last edited:
Why?
With pull-filter ignore "cipher" i can easily connect with blowfish, my problem is the HMAC error then ...
Or do you think, taht i can get rid of this error bei rejecting AES256?

GCM does not use HMAC-based authentication. If your provider's server is hardcoded for GCM, then it means they do not support HMAC's auth type, that is required for CBC ciphers. You can ensure you did configure it correctly on your side, by trying the Auth digest of either SHA1 or SHA256 (the two most common). But if their server is hardcoded for GCM, then they probably don't have any digest configured, which means you won't be able to use a CBC cipher.

You could probably solve all of these issues by contacting their tech support, since a lot of it lies with the configuration on their end. As the client side, you have only very limited control as to which parameter you can change, you are limited to what is configured on the server side.
 
Thx, so ive done for a few minutes ...

NordVPN tutorial is with 380,59, no problem with this version ;-)
 
@netguru, this has been an interesting read for me. Strange that NVPN gives you a configuration to use, then pushes a different configuration to you on the client side, which overrides your settings. Also interesting that NVPN instructions use the remote-random option:

remote-random
When multiple --remote address/ports are specified, or if connection profiles are being used, initially randomize the order of the list as a kind of basic load-balancing measure.

Which makes me wonder if you are not connecting to the server you specified. But another one in a list of servers, which has been setup to push the configs to you. Perhaps they do this in case your primary server is down and route you to another. Anyway, let us know how it works out for you. You may want to document your setup in the VPN forum to help other NVPN customers once you get it working.
 
https://fossies.org/linux/openvpn/Changes.rst

Data channel cipher negotiation

Data channel ciphers (--cipher) are now by default negotiated. If a client advertises support for Negotiable Crypto Parameters (NCP), the server will choose a cipher (by default AES-256-GCM) for the data channel, and tell the client to use that cipher. Data channel cipher negotiation can be controlled using --ncp-ciphers and --ncp-disable.
 
https://fossies.org/linux/openvpn/Changes.rst

Data channel cipher negotiation

Data channel ciphers (--cipher) are now by default negotiated. If a client advertises support for Negotiable Crypto Parameters (NCP), the server will choose a cipher (by default AES-256-GCM) for the data channel, and tell the client to use that cipher. Data channel cipher negotiation can be controlled using --ncp-ciphers and --ncp-disable.
Good info! I looked at the code, and it's not explicitly disabling the cipher negotiation if it's set to disabled.
Try
removing the pull-filter, set Cipher negotiation to disabled, and add

ncp-disable

in the custom config.
 
Good info! I looked at the code, and it's not explicitly disabling the cipher negotiation if it's set to disabled.
Try
removing the pull-filter, set Cipher negotiation to disabled, and add

ncp-disable

in the custom config.

I'll need to re-read the ncp-cipher section in the manual. The NCP documentation is somewhat confusing, due to their attempts at improving compatibility with various fallback scenarios.

Adding ncp-disable to the config when NCP is set to disabled on the webui would probably be a good idea, I'll look into it.
 
I'll need to re-read the ncp-cipher section in the manual. The NCP documentation is somewhat confusing, due to their attempts at improving compatibility with various fallback scenarios.

Adding ncp-disable to the config when NCP is set to disabled on the webui would probably be a good idea, I'll look into it.
Confusing.....yeah, I'd say so.

One line insert to add it.....the structure is already in place.
 
WORKS!

using "ncp-disable" it works ;-)
if you could add in the next alpha to test, would be fine !

Apr 7 20:22:16 openvpn[1968]: OpenVPN 2.4.1 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Apr 2 2017
Apr 7 20:22:16 openvpn[1968]: library versions: OpenSSL 1.0.2k 26 Jan 2017, LZO 2.08
Apr 7 20:22:16 openvpn[1969]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Apr 7 20:22:16 openvpn[1969]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Apr 7 20:22:16 openvpn[1969]: LZO compression initializing
Apr 7 20:22:16 openvpn[1969]: Control Channel MTU parms [ L:1626 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Apr 7 20:22:16 openvpn[1969]: Data Channel MTU parms [ L:1626 D:1300 EF:126 EB:407 ET:0 EL:3 ]
Apr 7 20:22:16 openvpn[1969]: Fragmentation MTU parms [ L:1626 D:1300 EF:125 EB:407 ET:1 EL:3 ]
Apr 7 20:22:16 openvpn[1969]: Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1546,tun-mtu 1500,proto UDPv4,comp-lzo,mtu-dynamic,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Apr 7 20:22:16 openvpn[1969]: Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1546,tun-mtu 1500,proto UDPv4,comp-lzo,mtu-dynamic,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Apr 7 20:22:16 openvpn[1969]: TCP/UDP: Preserving recently used remote address: [AF_INET]xxx7:1194
Apr 7 20:22:16 openvpn[1969]: Socket Buffers: R=[122880->122880] S=[122880->122880]
Apr 7 20:22:16 openvpn[1969]: UDP link local: (not bound)
Apr 7 20:22:16 openvpn[1969]: UDP link remote: [AF_INET]xxx:1194
Apr 7 20:22:16 openvpn[1969]: TLS: Initial packet from [AF_INET]xxx:1194, sid=d64481dd 96b87694
Apr 7 20:22:16 openvpn[1969]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Apr 7 20:22:17 openvpn[1969]: VERIFY OK: depth=1, C=NV, ST=NV, L=nVPN, O=nVpn, CN=nVpn CA, emailAddress=support@nvpn.net
Apr 7 20:22:17 openvpn[1969]: VERIFY OK: depth=0, C=NV, ST=NV, L=nVPN, O=nVpn, CN=server, emailAddress=support@nvpn.net
Apr 7 20:22:17 openvpn[1969]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
Apr 7 20:22:17 openvpn[1969]: [server] Peer Connection Initiated with [AF_INET]84.200.65.57:1194
Apr 7 20:22:18 openvpn[1969]: SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Apr 7 20:22:19 openvpn[1969]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,route xx,topology net30,ping 10,ping-restart 120,ifconfig xxx,peer-id 0'
Apr 7 20:22:19 openvpn[1969]: OPTIONS IMPORT: timers and/or timeouts modified
Apr 7 20:22:19 openvpn[1969]: OPTIONS IMPORT: --ifconfig/up options modified
Apr 7 20:22:19 openvpn[1969]: OPTIONS IMPORT: route options modified
Apr 7 20:22:19 openvpn[1969]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Apr 7 20:22:19 openvpn[1969]: OPTIONS IMPORT: peer-id set
Apr 7 20:22:19 openvpn[1969]: OPTIONS IMPORT: adjusting link_mtu to 1629
Apr 7 20:22:19 openvpn[1969]: Data Channel MTU parms [ L:1549 D:1300 EF:49 EB:407 ET:0 EL:3 ]
Apr 7 20:22:19 openvpn[1969]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Apr 7 20:22:19 openvpn[1969]: WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Apr 7 20:22:19 openvpn[1969]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Apr 7 20:22:19 openvpn[1969]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Apr 7 20:22:19 openvpn[1969]: WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Apr 7 20:22:19 openvpn[1969]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Apr 7 20:22:19 openvpn[1969]: WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.
Apr 7 20:22:19 openvpn[1969]: TUN/TAP device tun12 opened
Apr 7 20:22:19 openvpn[1969]: TUN/TAP TX queue length set to 100
Apr 7 20:22:19 openvpn[1969]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Apr 7 20:22:19 openvpn[1969]: /usr/sbin/ip link set dev tun12 up mtu 1500
 
Last edited:
Hi everybody here,
I cannot more start OVPN server on my RT-AC87U router. The log reports that error msg:
openvpn[22567]: Options error: Unrecognized option or missing or extra parameter(s) in config.ovpn:26: push (2.4.0)
That problem starts from updating to OVPN v2.4. The FW version is Merlin 380.65.4.
Until previous FW 380.64.2 the OVPN server works fine.
Someone here could help me about that issue ?? Many thanks in advance.
 
Hi everybody here,
I cannot more start OVPN server on my RT-AC87U router. The log reports that error msg:
openvpn[22567]: Options error: Unrecognized option or missing or extra parameter(s) in config.ovpn:26: push (2.4.0)
That problem starts from updating to OVPN v2.4. The FW version is Merlin 380.65.4.
Until previous FW 380.64.2 the OVPN server works fine.
Someone here could help me about that issue ?? Many thanks in advance.
Do you have an any options in the Additional Config section? Try removing those. From the message, it looks like you may have one it does not like. The only thing I found between 380.64 and 380.65 on the OpenVPN server is that I must specify compression. None no longer works. Chose one of the adaptive ones such as LZ0 or LZ4.
 
I'm having an issue with the Traffic Analyzer under 380.65.2. with my RT-AC88U. Basically the problem is as such:

1. Any traffic downloaded over WiFi shows up under not only the appropriate Wireless (5 GHz) tab, but also incorrectly under the Wired tab.
2. Any traffic uploaded over WiFi only shows up under the Wired tab, which is wrong.

I didn't test test 2.4 Ghz, but switching to the last 24 view I do see uploads and downloads, so that may be working. For the 5 Ghz views, no uploads are listed over the last 24 hours which is wrong. I tested with my laptop, iPhone and iPad, all connected to the 5 GHz network.

This has confused me greatly and I spent about 15 minutes pulling wires trying to figured out which of my wired devices was uploading before finally figuring out it was my iPhone doing so and the Traffic Analyzer was reporting the wrong info.

Is there a way to fix this so that the traffic shows up under the correct tab?
 
thanks a lot Xentrk for answering .... Solved!
I just delete the command in custom configuration "push route 192.168.1.0 255.255.255.0" and all work fine again.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top