If I run `openvpn --config /tmp/openvpn/openvpn.cnf` it seems to start alright and I can at least use netcat to connect to the server from outside my network, even if I haven't tried using an OpenVPN client yet.
But I can't find any invocation of `startservice openvpn` etc. that would make the service run for me.
Interestingly, trying to access the Status → OpenVPN page seems to hang httpd and require restarting that service.
Here's syslog after a reboot:
Code:
Jan 1 00:00:09 DD-WRT daemon.notice openvpn[925]: OpenVPN 2.4.1 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on May 2 2017
Jan 1 00:00:09 DD-WRT daemon.notice openvpn[925]: library versions: OpenSSL 1.0.2k 26 Jan 2017, LZO 2.09
Jan 1 00:00:09 DD-WRT daemon.notice openvpn[980]: MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:14
Jan 1 00:00:09 DD-WRT daemon.warn openvpn[980]: 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
Jan 1 00:00:09 DD-WRT daemon.warn openvpn[980]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jan 1 00:00:09 DD-WRT daemon.notice openvpn[980]: Diffie-Hellman initialized with 2048 bit key
Jan 1 00:00:09 DD-WRT daemon.warn openvpn[980]: WARNING: Your certificate is not yet valid!
Jan 1 00:00:09 DD-WRT daemon.notice openvpn[980]: TUN/TAP device tap2 opened
Jan 1 00:00:09 DD-WRT daemon.notice openvpn[980]: TUN/TAP TX queue length set to 100
And here's the service running after reboot:
Code:
root@DD-WRT:~# ps | grep openvpn
980 root 2996 S /tmp/openvpnserver --config /tmp/openvpn/openvpn.con
998 root 1148 S {route-up.sh} /bin/sh /tmp/openvpn/route-up.sh
1229 root 1148 S sh -c /etc/openvpnstate.sh > /tmp/.temp
1230 root 1152 S {openvpnstate.sh} /bin/sh /etc/openvpnstate.sh
1235 root 1152 S {openvpnstate.sh} /bin/sh /etc/openvpnstate.sh
1373 root 1148 S grep openvpn
but it doesn't actually seem to be listening for inbound connections:
Code:
root@DD-WRT:~# netstat -l
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 1 0 localhost:14 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:www 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:domain 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:telnet 0.0.0.0:* LISTEN
netstat: /proc/net/tcp6: No such file or directory
udp 0 0 0.0.0.0:domain 0.0.0.0:*
udp 0 0 localhost:34954 0.0.0.0:*
netstat: /proc/net/udp6: No such file or directory
netstat: /proc/net/raw6: No such file or directory
Active UNIX domain sockets (only servers)
Proto RefCnt Flags Type State I-Node Path
Last edited by virtualprivatenotworking on Mon May 29, 2017 20:56; edited 1 time in total
Ok, setting aside the fact that `openvpnserver` wasn't running at all before I rebooted, here's what I've determined.
The `openvpnserver` seems to be hanging during initialization. It does not respond at all on its management port. That explains why the Status → OpenVPN page was hanging, because it was waiting for it to respond on the management port. And it's probably hanging before it opens the VPN port.
But what it appears to be doing is executing the route-up.sh script:
Code:
root@DD-WRT:~# ps | grep openvpn
2626 root 2996 S /tmp/openvpnserver --config /tmp/openvpn/openvpn.conf --route-up /tmp/openvpn
2628 root 1148 S {route-up.sh} /bin/sh /tmp/openvpn/route-up.sh
2643 root 1148 S grep openvpn
And *that* script is what's hanging. We can see it just runs a handful of commands, so figuring out which one is stuck just involves grepping the process list a few times:
Code:
root@DD-WRT:~# ps | grep ebtables
1016 root 768 R ebtables -t nat -D POSTROUTING -o tap2 --pkttype-type multicast -j DROP
2006 root 768 R ebtables -t nat -D POSTROUTING -o tap2 --pkttype-type multicast -j DROP
2171 root 768 R ebtables -t nat -D POSTROUTING -o tap2 --pkttype-type multicast -j DROP
2459 root 1148 S sh -c /usr/sbin/ebtables -t nat -D POSTROUTING -o tap2 --pkttype-type multica
2460 root 768 R /usr/sbin/ebtables -t nat -D POSTROUTING -o tap2 --pkttype-type multicast -j
2519 root 768 R ebtables -t nat -D POSTROUTING -o tap2 --pkttype-type multicast -j DROP
2637 root 768 R ebtables -t nat -D POSTROUTING -o tap2 --pkttype-type multicast -j DROP
2678 root 1148 S grep ebtables
So that's what we're stuck on. And I can confirm by running that `ebtables -t nat -D POSTROUTING -o tap2 --pkttype-type multicast -j DROP` command myself that it doesn't exit, it just blocks.
The correct command to stop/start it is `stopservice openvpnserver`.
I found that by setting the `block_multicast` NVRAM variable to 1, I could get DD-WRT to not emit the ebtables commands, which sidestepped the problem.
The issue has been narrowed down to be caused by an improperly compiled ebtables binary.
A temporary workaround is described in the following thread including a jffs & startup script based implementation that survives reboot two posts down in the thread.
