Has anyone tried setting up a OpenVPN Server in the Omnia? Any lessens learned?
I’m thinking of trying the OpenVPN Server HowTo (Streamlined)
Would that be a ok guide to follow for Omnia?
Thanks
Daniel
I was about to start, but i have to go somewhere, so right now not really have the time…
I was looking at this one…
Well the guide is quite complex and have at least two unverifiable claims which I personally don’t agree with:
- Easy-RSA does not create secure enough certs & has too many limitations, therefore OpenSSL should be utilized directly via an openssl.cnf
- A non-standard port (not 1194) should be utilized for the VPN
This one look better, but it may be way too brief.
Thanks, will have a look at that one instead!
I have used this guide
https://wiki.openwrt.org/doc/howto/vpn.openvpn
used tap, works properly.
pavel
1 Like
Hi,
I am currently trying to setup a routed (tun) openvpn. I did this before on an older openwrt router and it was working fine.
Now I tried to copy my setup to turris omnia and I am having some issues. I can connect to the openvpn server and the connected clients can reach the router (192.168.1.1) and can use the internet through the vpn. (although names resoltion through dns does not work, even though I push a dns server to the client). However, I have problems to connect other computers located on the lan from a vpn client. I can not ping them, but for some reason I can access them via http (I have a computer located on the local network running an http server at port 8080 which I can reach from a connected vpn client). Other network traffic such as icmp ping or acessing smb shares does not work.
I have looked at the guide (https://wiki.openwrt.org/doc/howto/vpn.openvpn but did not find any error in my configuration.
My configuration looks like this:
openvpnconfig::
config openvpn 'server’
option port '1194’
option proto 'udp’
option dev 'tun’
option ca '/etc/openvpn/ca.crt’
option cert '/etc/openvpn/server.crt’
option key '/etc/openvpn/server.key’
option dh '/etc/openvpn/dh1024.pem’
option server '10.8.0.0 255.255.255.0’
option ifconfig_pool_persist '/tmp/ipp.txt’
option keepalive '10 120’
option persist_key '1’
option persist_tun '1’
option user 'nobody’
option status '/tmp/openvpn-status.log’
option log '/tmp/openvpn.log’
option verb '3’
option enabled '1’
list push 'dhcp-option DNS 192.168.1.1’
list push 'route 192.168.1.0 255.255.255.0’
list push 'redirect-gateway def1’
option comp_lzo ‘adaptive’
firewall
config rule
option target 'ACCEPT’
option proto 'tcp udp’
option dest_port '1194’
option name 'OPEN VPN’
option src ‘*’
config zone
option input 'ACCEPT’
option output 'ACCEPT’
option name 'VPN’
option network 'OpenVPN’
option forward ‘REJECT’
config forwarding
option dest 'lan’
option src 'VPN’
config forwarding
option dest 'wan’
option src ‘VPN’
Hi again,
I now found out that their is actually no problem in the configuration I posted - the problem is the windows 10 machine I was trying to reach. After the windows 10 machine got connected to the new omnia router the network was reset to “public network” so that my previously made firewall settings did no longer apply.
In order to allow communication with the openvpn subnet, I added it to the “scope” section in the windows firewall rules. Now that the rules are back everything is working as intended.
I have the same problem.
If I push DNS 8.8.8.8, the DNS works correctly.
DNS 192.168.1.1 is not resolving requests from the VPN subnet
From the VPN I can verify that port 53 is open on 192.168.1.1
I forgot to mention in my last post that in order to avoid the dns resolution problem I am now pushing a dns server different from the omnia. So you are right, we both have the same DNS problem, the omnia does not respond to DNS queries originating from the vpn.
Which client do you use? and which platform?
In my Omnia, I use Google DNS (8.8.8.8).
I am pushing 192.168.1.1 to the OpenVPN clients, because I am planning to set up a ad blocker in my router.
I used 2 Android applications and both of them receive the DNS (192.168.1.1), but the cannot resolve.
On of this application required an ovpn file, and it is available for iOS.
The iOS version was using the Google DNS correctly, as forwarded request.
For those using dnsmasq for DNS, here is something new:
Dnsmasq starts with local-service option, which means, that it will serve only requests from the subnets, that are local to interfaces. The thing is, that the tun0 interface used by OpenVPN does not exists yet, when dnsmasq starts. (Dnsmasq starts with priority 60 and OpenVPN with priority 90).
If I restart dnsmasq after OpenVPN start, the DNS over VPN works fine.
Now, dnsmasq should restart after new interface appears, at least according to /etc/hotplug.d/iface/25-dnsmasq. However, I’m not sure it does - calling /etc/init.d/dnsmasq start finishes way faster than calling /etc/init.d/dnsmasq restart. Here, more research will be needed.
Have you set up a logical interface for the VPN tunnel? Like this in /etc/network/interfaces/etc/config/network:
config interface 'vpn'
option ifname 'tun0'
option proto 'none'
Then, netifd would detect whenever your device comes up and fire an appropriate hotplug event.
I used the clicky way through luci, which created this entry in /etc/config/network (not /etc/network/interfaces, it does not exist):
config interface 'openvpn'
option ifname 'tun0'
option _orig_ifname 'tun0'
option _orig_bridge 'false'
option proto 'none'
option auto '1'
I’m soon jumping onto this bandwagon…
…but I need to tweak some other Omnia stuff first, so there is still time for you guys to hide! 
That should be enough.
I see that in your firewall zone definition, you list the interface as OpenVPN even though its name is openvpn. This could be the issue.
Then, see the logs. You should see there information that the openvpn got up, firewall got restarted and dnsmasq probably as well.
That’s different guy, who has interface named OpenVPN 
For the completness, my firewall config:
to allow incoming openvpn traffic from wan:
config rule
option enabled '1'
option target 'ACCEPT'
option src 'wan'
option proto 'tcp udp'
option dest_port '1194'
option name 'OpenVPN'
to create vpn_ovpn zone and allow forwarding to/from lan:
config zone
option input 'ACCEPT'
option forward 'REJECT'
option output 'ACCEPT'
option name 'vpn_ovpn'
option network 'openvpn'
config forwarding
option dest 'lan'
option src 'vpn_ovpn'
config forwarding
option dest 'vpn_ovpn'
option src 'lan'
Again, it was created through luci. The only thing I didn’t create through luci was openvpn config, because the options for creating the profile were something completely different than I had in my old config - so I just copied the old config over.
Everything was working, the traffic was passing through, except for DNS responses. Because there was no firewall rule that would block 53/tcp or 53/udp and the dnsmasq was listening on 0.0.0.0:53, there had to be something else.
It turned out that dnsmasq didn’t know about the tun0 interface. As I mentioned in the previous post, the hotplug scripts calls /etc/init.d/dnsmasq start. I tried to run it by hand, but it finished immediately and not much happened. Only running /etc/init.d/dnsmasq restart had an effect.
1 Like
Thanks! It looks like it has been fixed in the LEDE project. I’ve reported the issue to the Turris Team so they can apply the fix.
I noticed that the new version of TurrisOS (3.3) has this commit applied (at least from a cursory look at the init script), but it doesn’t seem it is enough: every time I start the VPN I have to restart dnsmasq, or I have issues with wireless clients not being able to leave the LAN.
This assuming is that I’m experiencing the same problem.
I’ve got two Turris routers that I want to have VPN between. Via the Luci interface I can enable both server and client. I think I need both don’t I? TAP or TUN? I’m reading on https://wiki.openwrt.org/doc/howto/vpn.openvpn and I also read the comment about SSL. Should I configure with SSL alone? Thanks
You don’t need TAP unless you need applications that require a “real” network interface (such as Windows file sharing). For most uses, TUN is sufficient.