OpenVPN server easy and fast

UDP1194 should be already opened. And there is no need to open other ports to WAN.

Especially it is unwise to open port 53 to WAN. You router could be abused to perform some DNS amplification attack.

Not so easy and fast (for beginners)…

My attempts to use OpenVPN acces from Win10 client failed:
Mon Mar 20 14:33:15 2017 OpenVPN 2.4.0 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Jan 31 2017
Mon Mar 20 14:33:15 2017 Windows version 6.2 (Windows 8 or greater) 64bit
Mon Mar 20 14:33:15 2017 library versions: OpenSSL 1.0.2k 26 Jan 2017, LZO 2.09
Enter Management Password:
Mon Mar 20 14:33:15 2017 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Mon Mar 20 14:33:15 2017 Need hold release from management interface, waiting…
Mon Mar 20 14:33:15 2017 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Mon Mar 20 14:33:15 2017 MANAGEMENT: CMD 'state on’
Mon Mar 20 14:33:15 2017 MANAGEMENT: CMD 'log all on’
Mon Mar 20 14:33:15 2017 MANAGEMENT: CMD 'hold off’
Mon Mar 20 14:33:15 2017 MANAGEMENT: CMD 'hold release’
Mon Mar 20 14:33:15 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]88.xxx.xxx.xxx:1194
Mon Mar 20 14:33:15 2017 Socket Buffers: R=[65536->65536] S=[65536->65536]
Mon Mar 20 14:33:15 2017 UDP link local: (not bound)
Mon Mar 20 14:33:15 2017 UDP link remote: [AF_INET]88.xxx.xxx.xxx:1194
Mon Mar 20 14:33:15 2017 MANAGEMENT: >STATE:1490016795,WAIT,
Mon Mar 20 14:33:15 2017 read UDP: Connection reset by peer (WSAECONNRESET) (code=10054)
Mon Mar 20 14:33:17 2017 read UDP: Connection reset by peer (WSAECONNRESET) (code=10054)
Mon Mar 20 14:33:22 2017 read UDP: Connection reset by peer (WSAECONNRESET) (code=10054)
Mon Mar 20 14:33:31 2017 read UDP: Connection reset by peer (WSAECONNRESET) (code=10054)
Mon Mar 20 14:33:47 2017 read UDP: Connection reset by peer (WSAECONNRESET) (code=10054)
Mon Mar 20 14:34:15 2017 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Mar 20 14:34:15 2017 TLS Error: TLS handshake failed
Mon Mar 20 14:34:15 2017 SIGUSR1[soft,tls-error] received, process restarting
Mon Mar 20 14:34:15 2017 MANAGEMENT: >STATE:1490016855,RECONNECTING,tls-error,
Mon Mar 20 14:34:15 2017 Restart pause, 5 second(s)
Mon Mar 20 14:34:16 2017 SIGTERM[hard,init_instance] received, process exiting
Mon Mar 20 14:34:16 2017 MANAGEMENT: >STATE:1490016856,EXITING,init_instance,

For the record: Turris Omnia, Czec Republic, O2.cz VDSL 50/5

Any clue what failed?

Thx

Michal

Are you sure that the openvpn server is running on you router?

It seems that you can’t connect to the server. The success sequence should continue like this:

Mon Mar 20 16:21:06 2017 UDP link local: (not bound)
Mon Mar 20 16:21:06 2017 UDP link remote: [AF_INET]172.20.6.149:1194
Mon Mar 20 16:21:06 2017 TLS: Initial packet from [AF_INET]172.20.6.149:1194, sid=cf489b9d 01ec35be
Mon Mar 20 16:21:06 2017 VERIFY OK: depth=1, CN=openvpn
Mon Mar 20 16:21:06 2017 Validating certificate key usage
...

shenek: Are you sure that the openvpn server is running on you router?
BINGO! I didn´t realize the service IS NOT running - and that´s not easy and foolproof :slight_smile: Service enabled and start in LuCi + 1 restart. Now I can use my LTE stick to connect to my home network.
(There´s some work to do - for example to connect my W10 PC. And not only satelite receiver, simple NAS and Turris. But so far so good.)
Many thanks!

Michal

Thank you for the suggestion.
I modified /etc/config/firewall, with your suggestion, so the forwarding rules now look like this:

config forwarding 'vpn_turris_forward_lan_in'
	option src 'vpn_turris'
	option dest 'lan'

config forwarding 'vpn_turris_forward_lan_out'
	option src 'lan'
	option dest 'vpn_turris'

config forwarding 'vpn_turris_forward_wan_out'
	option src 'vpn_turris'
	option dest 'wan'

and also edited /etc/config/openvpn to ensure it contained the following:

list push 'route 192.168.2.0 255.255.255.0'     # My network is 192.168.2.0
list push 'dhcp-option DNS 8.8.8.8'
list push 'dhcp-option DNS 8.8.4.4'
list push 'redirect-gateway def1'

Then tested on my iPhone with `OpenVpn Client App, and lo and behold, the public IP on the iPhone had changed to my WAN’s public IP. Web surfing also worked, but with a slight, but noticeable, lag compared to before. (A local DNS cache will probably help a lot).

Whats even stranger, the Turris OpenVPN Server configuration, which wasn’t showing any entries the last two days, and really had me worried, now suddenly shows everything as if nothing happened.

I’m a really happy man now! :relaxed::relaxed::relaxed:

Thank you very much for your help!!!

2 Likes

I’ve posted instructions on how to compile openvpn 2.4 for the turris omnia here:

Haven’t tested it out yet functionality-wise, but will later in the week.

As the devs weren’t very helpful, here is the template:

git Template

You wanna at your options after line 327, when I have time I’ll test some necessary commands, if somebody is faster, input is always welcome.

1 Like

I will summarize how to setup OpenVPN the same way as basically @Koleon wanted (route all traffic with local DNS resolving). I was experimenting with it for two hours before I’ve finally make it work.

Prerequisites:

  1. You obviously have to enable OpenVPN through Foris interface
  2. I’ve also enabled OpenVPN to start automatically by running /etc/init.d/openvpn enable
  3. Go to LuCI http://192.168.1.1/cgi-bin/luci/admin/network/dhcp and uncheck/disable option Local Service Only under General settings tab (this was the thing I was missing in this discussion but it makes local name resolving working for me finally)

Then there are two ways how to do the other steps. By editing config files manually or through uci.

Manually:
Edit /etc/config/firewall, add those lines to the end:

config forwarding 'vpn_turris_forward_wan_out'
	option src 'vpn_turris'
	option dest 'wan'

Reload firewall’s config: /etc/init.d/firewall reload

Edit /etc/config/openvpn, add those lines to the end of config openvpn 'server_turris' section:

	list push 'redirect-gateway def1'
	list push 'dhcp-option DNS 192.168.1.1'

Restart openvpn server: /etc/init.d/openvpn restart

With UCI:

uci set firewall.vpn_turris_forward_wan_out=forwarding
uci set firewall.vpn_turris_forward_wan_out.src=vpn_turris
uci set firewall.vpn_turris_forward_wan_out.dest=wan
uci add_list openvpn.server_turris.push='redirect-gateway def1'
uci add_list openvpn.server_turris.push='dhcp-option DNS 192.168.1.1'
uci commit
/etc/init.d/firewall reload
/etc/init.d/openvpn restart
1 Like

Unfortunatelly localservice doesnt help me with DNS, still the same results, google DNS works, router DNS doesnt :frowning:

I see this option under dnsmasq, did you use it instead kresd?

I had all of this working as I wanted, till the other day, where I decided to install an mSATA disk in the device.

After installing the mSATA, and making the needed changes to the /etc/config/wireless file, I had my system back online - or so I thought.
It turns out my OpenVPN isn’t accessible from my iPhone any more. Whenever I attempt to connect, I now get connection timeouts. Other VPN connections from the iPhone works as they should.

Any idea how I can debug this?

I see it configured in /etc/config/dhcp and I have running dnsmasq, kresd is not running on my system…

ah, that would be it… Omnia in default configuration using kresd, so we need propably similiar setting for kresd :frowning:

Found the problem: The OpenVPN service wasn’t enabled and thus not running.

But why it has been disabled is a big mystery for me!!!

As I read the thread, @MiSko had a similar problem some days ago, so this might be something for the devs to look into?

It is because it is not starting on boot.
Easily solved to toggeling it to enabled in LuCI under System >>> Startup.

Out of curiosity I’ve tried to configure kresd (by following Dnsmasq .lan domain while still using knot resolver post)…

What worked for me under OpenVPN was to change IP address from 192.168.1.1 to 10.111.111.1, so now I have following in /etc/config/openvpn:

	list push 'dhcp-option DNS 10.111.111.1'

Output from dig command helped a lot with debugging as with 192.168.1.1 IP the result was:

$ dig @192.168.1.1 -t ANY omnia.lan
;; reply from unexpected source: 10.111.111.1#53, expected 192.168.1.1#53

Thanks @iddqd, this was exactly what I did (and attempted to write above).

The mystery remains, though - why did it suddenly change to not start on boot?

After setting up OpenVPN, I did reboot least 15 times, and each time the VPN setup remained working.
The only difference I can think of this time, is that I powered down the device completely to install the mSATA.
So perhaps we have some settings that somehow survives a reboot?

I didnt configure dnsmasq at all (and still, my .lan works). I tried the dig on my LAN subnet IP (which actually doesnt works as pushed DNS via OpenVPN), and from omnia I have different result (it doesnt point me to any other IP):

; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 39446
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Well, it kind of works for me, but only for couple of seconds (about 15). I used installation trough Foris. I extracted certs and keys from downloaded configuration file and created VPN configuration manually trough GUI in Ubuntu. Then, I was able to connect and ping my NAS at 192.168.0.147. But after few seconds it stopped working. I disconnected from VPN and connect again. It started working but after another couple of seconds it failed again. I have no idea why is this happening.

> openvpn --version
OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec  1 2014

> uname -a
Linux Cejhon-NTB 3.13.0-96-generic #143-Ubuntu SMP Mon Aug 29 20:15:20 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

> ifconfig
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
      inet addr:192.168.1.6  P-t-P:192.168.1.5  Mask:255.255.255.255
      UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
      RX packets:36 errors:0 dropped:0 overruns:0 frame:0
      TX packets:52 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:100 
      RX bytes:4004 (4.0 KB)  TX bytes:5454 (5.4 KB)

wlan0     Link encap:Ethernet  HWaddr dc:a9:71:19:82:b4  
      inet addr:192.168.1.131  Bcast:192.168.1.255  Mask:255.255.255.0
      inet6 addr: fe80::dea9:71ff:fe19:82b4/64 Scope:Link
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:72595 errors:0 dropped:0 overruns:0 frame:0
      TX packets:63814 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000 
      RX bytes:63975155 (63.9 MB)  TX bytes:12927280 (12.9 MB)

Lokální síť mám 192.168.0.0/24 a při generování configurace VPN jsem nastavil 192.168.1.0/24. To je předpokládám správně, když se mi to alespoň na chvíli připojí.

Připojení na mobilu mi ale drží.

Hey,
thanks man for the settings. Unfortunately I won’t be able to test it out any sooner than at the weekend.

Other features that would be nice to have :slight_smile: :

  1. generate client_file .ovpn instead of client_file .conf by default (Becase of Windows importing process)
  2. Run the openvpn server as unprivileged user (e.g. nobody:nogroup)
  3. generate and secure the communication with tls-auth ta.key by default
2 Likes

That’s indeed weird and it should not happen. Is there something useful in the logs?
Anyways, if you want to make it bulletproof you could write a small script to check if OVPN is running and if necessary to start it.