I'm using an ASUS RT-N66U
Firmware: DD-WRT v3.0-r31544 (02/28/17)
On my (Windows 10) PC, I'm using OpenVPN GUI v2.4.0 with the TAP Adapter v9.21.2.
For testing purposes, my router is default 192.168.1.1 and my computer is connected directly to it with an auto-assigned IP of 192.168.1.148.
After generating the keys (per the instructions referenced in the above link), and inputting the keys according to that link, I set the options in DD-WRT -> VPN as follows:
I used this config on the client (Windows PC) side:
Code:
client
dev tap
proto udp
remote 192.168.1.1 1194
nobind
persist-key
persist-tun
verb 4
float
ca ca.crt
cert theorie-gs60.crt
key theorie-gs60.key
comp-lzo yes
tun-mtu 1500
auth SHA1
cipher AES-128-CBC
Of course, being that I'm connected to the router directly as a DHCP client and a VPN client, I'm getting loopbacks, but I'm assuming that won't happen once I disconnect from the router and connect remotely.
I van confirm it works on my end too. But with a few oddities.
First of all, on the dd-wrt side it all seems to work perfectly. On the client side (my laptop) however, a few strange things happen. My laptop is connected through WiFi but the VPN connection is made through the Ethernet adapter.
When not connected through VPN, ipconfig shows this:
Code:
Ethernet adapter Ethernet:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
So the VPN connection is made through the Ethernet adapter and not through the wireless adapter. This means that I *am* able to see the shared resources on my network (at home), but browsing the internet is still done with my local IP address.
I would think the option redirect default gateway would work on server side. There should also be a client side option to send all traffic over the vpn.
Posted: Mon Dec 11, 2017 0:25 Post subject: vpn assist
I am also using an RTN66U. and recently switched from Tomato to DD-WRT. Tomato I used a static key, which I can't seem to make work with DD-WRT. I have my logs an error about unable to Cannot load certificate file /tmp/openvpn/cert.pem. Most documentation seems to be out of date or not very helpful. Any thoughts you might have?
ec 11 00:22:11 RTN66U user.info : openvpn : OpenVPN daemon (Server) starting/restarting...
Dec 11 00:22:11 RTN66U daemon.notice openvpn[16275]: OpenVPN 2.4.4 mipsel-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Dec 4 2017
Dec 11 00:22:11 RTN66U daemon.notice openvpn[16275]: library versions: OpenSSL 1.1.0g 2 Nov 2017, LZO 2.09
Dec 11 00:22:11 RTN66U daemon.notice openvpn[16277]: MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:14
Dec 11 00:22:11 RTN66U daemon.warn openvpn[16277]: NOTE: when bridging your LAN adapter with the TAP adapter, note that the new bridge adapter will often take on its own IP address that is different from what the LAN adapter was previously set to
Dec 11 00:22:11 RTN66U daemon.warn openvpn[16277]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec 11 00:22:11 RTN66U daemon.notice openvpn[16277]: Diffie-Hellman initialized with 2048 bit key
Dec 11 00:22:11 RTN66U daemon.err openvpn[16277]: OpenSSL: error:140AB18E:lib(20):func(171):reason(398)
Dec 11 00:22:11 RTN66U daemon.err openvpn[16277]: Cannot load certificate file /tmp/openvpn/cert.pem
Dec 11 00:22:11 RTN66U daemon.notice openvpn[16277]: Exiting due to fatal error
Maybe it is because DDWRT uses the latest SSL, you have to regenerate your certificates with the latest OpenVPN/Easy-RSA.
Sometimes this can be mitigated by adding to the additional config:
Code:
tls-cipher "DEFAULT:@SECLEVEL=0"
Thank you that seemed to resolve the error, however I am puzzled and must be missing something. I downloaded the latest version of OpenVPN from their website a week or so ago. Is there any updated package somewhere that I still need to download?
Is there a guide for Windows and EASY RSA 3.0? I can't seem to find one that works with the EASY-RSA Shell.
FWIW, easyrsa v3 is also available from Entware, and thus can be run from the router itself (provided of course you're willing and able to install Entware). I just find it easier in some cases than dealing w/ Windows. And I have some scripts too that automate the process, which you could probably adapt for your own situation.
You don't *have* to use PKI (which requires easyrsa) for your own OpenVPN server. You could use a static key, or static key + username/password instead. Not as good as PKI, and has some limitations, but it's enough to get it working and useful in the short term. And the static key can be generated from the openvpn executable itself, no easyrsa installation required.
Code:
openvpn --genkey --secret static.key
Tomato I had setup using a static, I have everything working with the CAs now using the sites I listed prior.
Additional Config:
push "dhcp-option DNS 192.168.10.1"
tls-cipher "DEFAULT:@SECLEVEL=0"
Client .opvn file #1
- all traffic overVPN, except for certain sites
-----------------------------
client
remote .us 1194
dev tap1
cipher AES-256-CBC
proto udp
comp-lzo
cipher AES-256-CBC
auth SHA512
tls-cipher TLS-RSA-WITH-AES-256-CBC-SHA256
route-gateway 192.168.10.1
redirect-gateway def1
#Route perticular website to network interface instead of VPN interface
#Host Name :
route 0.0.0.0 255.255.255.255 net_gateway
route 0.0.0.0 255.255.255.255 net_gateway
route 0.0.0.0 255.255.255.255 net_gateway
route-method exe
route-delay 2
ca .crt
cert .crt
key .key
nobind
Client .opvn file #2
- LAN traffic overVPN, Web over Public
-----------------------------
client
remote .us 1194
dev tap1
cipher AES-256-CBC
proto udp
comp-lzo
cipher AES-256-CBC
auth SHA512
tls-cipher TLS-RSA-WITH-AES-256-CBC-SHA256
#Route perticular website to network interface instead of VPN interface
route 0.0.0.0 255.255.255.255 net_gateway
route 0.0.0.0 255.255.255.255 net_gateway
route 0.0.0.0 255.255.255.255 net_gateway
route-method exe
route-delay 2
ca .crt
cert .crt
key .key
nobind
It seems to work with tracert the way I would expect.
Client .opvn file #1
tracert sends 8.8.8.8 over 192.168.10.1
Client .opvn file #2
tracert sends 8.8.8.8 over 192.168.1.1 (the jetpack ip)
I do get a couple of errors in the logs that I have yet to google and I suspect I might not be negotiating the right TLS Cipher. I am not worth millions or that super paranoid, as long as its good enough for most public wifi.
Client Log
Enter Management Password:
Mon Feb 19 17:52:28 2018 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Mon Feb 19 17:52:29 2018 TCP/UDP: Preserving recently used remote address: [AF_INET].88:1194
Mon Feb 19 17:52:29 2018 UDP link local: (not bound)
Mon Feb 19 17:52:29 2018 UDP link remote: [AF_INET].88:1194
Mon Feb 19 17:52:30 2018 [DDWRTRTN66U] Peer Connection Initiated with [AF_INET].88:1194
Mon Feb 19 17:52:31 2018 open_tun
Mon Feb 19 17:52:31 2018 TAP-WIN32 device [TAP1] opened: \\.\Global\}.tap
Mon Feb 19 17:52:31 2018 Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.10.180/255.255.255.0 on interface {F} [DHCP-serv: 192.168.10.0, lease-time: 31536000]
Mon Feb 19 17:52:31 2018 Successful ARP Flush on interface [15] {EA437733-AAD7-487B-8B5E-3AE3EDFCD7CF}
Mon Feb 19 17:52:31 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Mon Feb 19 17:52:33 2018 Initialization Sequence Completed
Mon Feb 19 17:53:04 2018 SIGTERM[hard,] received, process exiting
Router Log:
20180219 17:41:30 TCL3QRR3Q1/174.232.2.207:9231 SENT CONTROL []: 'PUSH_REPLY redirect-gateway def1 dhcp-option DNS 192.168.10.1 route-gateway 192.168.10.1 ping 10 ping-restart 120 ifconfig 192.168.10.180 255.255.255.0 peer-id 0 cipher AES-256-GCM' (status=1)
20180219 17:41:30 .207:9231 Data Channel: using negotiated cipher 'AES-256-GCM'
20180219 17:41:30 .207:9231 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
20180219 17:41:30 .207:9231 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
20180219 17:41:30 207:9231 MULTI: Learn: -> .207:9231
Mon Feb 19 17:52:28 2018 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
I wouldn't be overly concerned about that message. Think of OpenVPN as the "nanny VPN". It likes to tell you about evvvvery possible thing that could and might go wrong. In this case, you can use one of several methods to insure the server's cert is who it claims to be.
To keep it hushed, add the following directive to the OpenVPN client.
Code:
remote-cert-tls server
The following would work just as well, but is scheduled for deprecation.
