OpenVPN server setup on WRT1200AC [solved]

Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Advanced Networking
Goto page Previous  1, 2
Author Message
Szellem
DD-WRT Novice


Joined: 14 Sep 2012
Posts: 16

PostPosted: Fri May 17, 2019 14:02    Post subject: Reply with quote
Nightbridge wrote:
No problem, sorry for the late reply.

That's very strange, to me it works like a charm. Have you tried by resetting the router with 30-30-30 method and applying those changes from GUI?

Are you using from both sides IPv4 or IPv6? I had problems in the past with IPv6 with this.


I haven't tried resetting, will keep that in mind! IPv4 on both sides, which I think I'm telling openvpn about with 'proto udp4'

Per Yngve Berg wrote:
With NAT, always state the output interface.

iptables -t nat -I POSTROUTING -o tun0 -j MASQUERADE

Check if the interface is tun0 or tun1.

The comp-lzo much also match on both sides.


Thanks, I'll have to go back through and refresh on the iptables situation.

eibgrad wrote:
JMTC.

Make sure whenever you're establishing an OpenVPN configuration that you use the *simplest* config possible. Don't add things that are optional (e.g., tls-auth), because it just creates another point of failure. KEEP IT SIMPLE! Once you have a working connection, THEN you can fuss and tweak it all you like.

One thing I've noticed about these connection failures from the OpenVPN client is that we never see the OpenVPN server logs! At the very least, we can tell if the OpenVPN client is reaching the OpenVPN server (even if it ultimately fails). And hopefully it will tell us more.

On the OpenVPN server side, all you need beyond the basic GUI elements is to push the local network on which the OpenVPN server is running over to the OpenVPN client, by adding the following directive in Additional Config.

Code:
push "route 192.168.1.0 255.255.255.0"


Of course, I'm just using 192.168.1.x as an example. Use whatever network is on the server side.

If you're doing anything more than that, you're making a mistake. Less is more! Time and again I see ppl get into trouble because they *over* configure the OpenVPN server and/or client.

Also, when it comes to compression, if the two sides are mismatched, they usually get connected, but no traffic can cross the tunnel. But from the perspective of the OpenVPN client logs, it doesn't seem to be getting connected at all.


Thanks for the suggestions! What you said about the simplest config makes sense, so I gave that a try and was able to make a connection! It's with the static key though, so I still need to go back and do the PKI stuff again.

I followed directions from: https://openvpn.net/community-resources/static-key-mini-howto/

The configs provided in that page did not work for me, so I adjusted them:

Server:
Code:

# cat static.conf
dev tun
ifconfig 10.8.0.1 10.8.0.2
secret static.key
proto udp4
verb 3


Client:
Code:

$ cat static.conf
remote my.url
dev tun
ifconfig 10.8.0.2 10.8.0.1
secret static.key
proto udp4
float


And I can ping:
Code:

$ ping 10.8.0.1
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=292 ms
64 bytes from 10.8.0.1: icmp_seq=2 ttl=64 time=237 ms
64 bytes from 10.8.0.1: icmp_seq=3 ttl=64 time=244 ms
^C
--- 10.8.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 236.894/257.685/292.153/24.551 ms


But the server still shows some errors while the connection is ongoing:
Code:

# openvpn --config static.conf
Fri May 17 08:51:21 2019 disabling NCP mode (--ncp-disable) because not in P2MP client or server mode
Fri May 17 08:51:21 2019 OpenVPN 2.4.6 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Dec 31 2018
Fri May 17 08:51:21 2019 library versions: OpenSSL 1.1.1a  20 Nov 2018, LZO 2.09
Fri May 17 08:51:21 2019 Outgoing Static Key Encryption: Cipher 'BF-CBC' initialized with 128 bit key
Fri May 17 08:51:21 2019 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).
Fri May 17 08:51:21 2019 Outgoing Static Key Encryption: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri May 17 08:51:21 2019 Incoming Static Key Encryption: Cipher 'BF-CBC' initialized with 128 bit key
Fri May 17 08:51:21 2019 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).
Fri May 17 08:51:21 2019 Incoming Static Key Encryption: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri May 17 08:51:21 2019 TUN/TAP device tun0 opened
Fri May 17 08:51:21 2019 TUN/TAP TX queue length set to 100
Fri May 17 08:51:21 2019 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Fri May 17 08:51:21 2019 /sbin/ifconfig tun0 10.8.0.1 pointopoint 10.8.0.2 mtu 1500
Fri May 17 08:51:21 2019 Socket Buffers: R=[180224->180224] S=[180224->180224]
Fri May 17 08:51:21 2019 UDPv4 link local (bound): [AF_INET][undef]:1194
Fri May 17 08:51:21 2019 UDPv4 link remote: [AF_UNSPEC]
Fri May 17 08:51:24 2019 Peer Connection Initiated with [AF_INET]ip:55116
Fri May 17 08:51:24 2019 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Fri May 17 08:51:24 2019 Initialization Sequence Completed
Fri May 17 08:54:04 2019 Authenticate/Decrypt packet error: packet HMAC authentication failed
Fri May 17 08:54:06 2019 Authenticate/Decrypt packet error: packet HMAC authentication failed
Fri May 17 08:54:07 2019 Authenticate/Decrypt packet error: packet HMAC authentication failed
Fri May 17 08:54:08 2019 Authenticate/Decrypt packet error: packet HMAC authentication failed
Fri May 17 08:54:14 2019 Authenticate/Decrypt packet error: packet HMAC authentication failed
Fri May 17 08:54:18 2019 Authenticate/Decrypt packet error: packet HMAC authentication failed
Fri May 17 08:54:19 2019 Authenticate/Decrypt packet error: packet HMAC authentication failed
Sponsor
Szellem
DD-WRT Novice


Joined: 14 Sep 2012
Posts: 16

PostPosted: Fri May 17, 2019 15:32    Post subject: Reply with quote
As a next step, I tried using the same configuration from the DD-WRT UI, but couldn't get it to work.



The generated config:
Code:

# cat /tmp/openvpn/openvpn.conf
secret /tmp/openvpn/static.key
keepalive 10 120
verb 3
mute 3
syslog
writepid /var/run/openvpnd.pid
management 127.0.0.1 14
management-log-cache 100
topology subnet
script-security 2
port 1194
proto udp4
cipher none
auth none
client-connect /tmp/openvpn/clcon.sh
client-disconnect /tmp/openvpn/cldiscon.sh
client-config-dir /tmp/openvpn/ccd
comp-lzo no
ifconfig-pool-persist /tmp/openvpn/ip-pool 86400
fast-io
tun-mtu 1500
mtu-disc yes
server 
dev tun2
ifconfig 10.8.0.1 10.8.0.2


And the server refuses to start:
Code:

May 17 15:13:35 bns-wrt user.info : openvpn : OpenVPN daemon (Server) starting/restarting...
May 17 15:13:35 bns-wrt daemon.err openvpn[8897]: Options error: --server and --secret cannot be used together (you must use SSL/TLS keys)


So it looks like I need to dive into TLS again to run this next test.
Szellem
DD-WRT Novice


Joined: 14 Sep 2012
Posts: 16

PostPosted: Fri May 17, 2019 21:41    Post subject: Reply with quote
Finally got it! Phew!

tl;dr I had to manually forward port 1194:


After rebuilding all of the PKI keys and certs and stuff, I got back to the same errors that I saw before. I did some more digging, and found a few resources like this: https://unix.stackexchange.com/questions/417113/openvpn-tls-handshake-hangs-at-p-control-hard-reset-server-v2-not-received

The gist of all of them is "The server isn't responding, something's up with the network side of things." With possible solutions from iptables to using the 'local' config word on the server to bind to a specific address. I toyed around with a few of them until finally just forwarding the port specifically, and was able to connect.

My current config:



Thank you all for the help! It took a few months, but we got it!
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 3650
Location: Netherlands

PostPosted: Sat May 18, 2019 8:37    Post subject: Reply with quote
Great that it is working, but I assume that the OVPN server is running on a secondary router?

If it is running on your primary router (connected to the internet a port forward is not necessary (DDWRT opens up the corresponding port on the INPUT chain)

_________________
Routers:Netgear R7800, Netgear R6400v1, Netgear R6400v2, Linksys EA6900 (XvortexCFE), Linksys E2000 (converted WRT320N), WRT54GS v1.
Install guide Linksys EA6900: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=291230
Simple PBR (Policy Based Routing) script: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=318662
Install guide R6400v2:http://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
OpenVPN server setup guide:
https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=318795
Install guide R7800: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Szellem
DD-WRT Novice


Joined: 14 Sep 2012
Posts: 16

PostPosted: Sat May 18, 2019 16:33    Post subject: Reply with quote
egc wrote:
Great that it is working, but I assume that the OVPN server is running on a secondary router?

If it is running on your primary router (connected to the internet a port forward is not necessary (DDWRT opens up the corresponding port on the INPUT chain)


Thanks egc. This is the main/only router for the network, its upstream IP is the WAN from my ISP.
Szellem
DD-WRT Novice


Joined: 14 Sep 2012
Posts: 16

PostPosted: Sat May 18, 2019 16:49    Post subject: Reply with quote
Well, and now I'm sitting at a coffee shop and cannot connect again. Same 'P_CONTROL_HARD_RESET_CLIENT_V2' errors as before.

Previously I'd been testing from a school wireless network, so I wouldn't expect just switching networks to cause trouble.
Szellem
DD-WRT Novice


Joined: 14 Sep 2012
Posts: 16

PostPosted: Wed May 22, 2019 17:27    Post subject: Reply with quote
The VPN didn't work at the coffee shop, but does at my office. It appears to be working OK, except that I cannot query the dd-wrt router for DNS names of local machines. I have dnsmasq set up as the DHCP host and also have local name resolution enabled.

Just in case it was a bug, last night I upgraded the router to v3.0-r39827 std (05/20/19)

But I still cannot resolve names:
Code:

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
[...]
192.168.13.0    192.168.14.1    255.255.255.0   UG    50     0        0 tun0
192.168.14.0    0.0.0.0         255.255.255.0   U     50     0        0 tun0

$ drill bns-wrt.bns @192.168.13.1
Error: error sending query: Could not send or receive, because of network error


*Edit: I also cannot resolve DNS from inside the network, with a local machine. So this isn't a openvpn issue, but dnsmasq one instead.
Goto page Previous  1, 2 Display posts from previous:    Page 2 of 2
Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Advanced Networking All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum