OpenVPN server with dynamic IP

Hi, I’m trying to configure my Omnia to connect from outside via OpenVPN. The official documentation ( is very clear and very simple in the basic configuration. My problem is that I have a public but dynamic IP. How I should behave? The documentation says to use a ddns service. I’ve used it in the past, configuring it via LuCI. But isn’t that a security risk, which thwarts VPN use? And how do I insert a domain name (the one provided by DDNS service) instead of the IP address in the configuration by (re) Foris? Can anyone clarify this for me? Thanks.

it depends way you needed VPN. if only as access to the home net you just need to send a daily dynamic ip to your email. example:
[ -e $ADRESA ] && TEST1=cat $ADRESA || TEST1=0

TEST=`ifconfig -a 3g-LTE |grep "inet addr" |cut -c 21-35`

if [ $TEST != $TEST1 ]; then
	create_notification -s news "Public IP: $TEST"
1 Like

I have to use the VPN to get into the home router and change some settings when I’m not at home.

There’s also WireGuard. Easier to set up than OpenVPN IMO.

Beautiful wireguard, I’m a big fan of it. But does this solve my dynamic IP question? Then to be honest I’d like to use the handy tools offered by Turris OS and reForis.

I don’t think you can do it with reForis.
You have to install DDNS packages in Luci, and configure it.
In the old interface (Foris) there was a field to specify the DNS name, but I don’t see thay in reForis.
Download the configuration for your client, edit “remote ip.xx.xx.xx 1194” with “remote your.dns 1194”.

Ok, thanks for the reply. I have recent experience with DDNS and LuCI. I set it up without any problems. But isn’t DDNS insecure? That is, anyone can access my subnet.

IMHO You are always exposed to the internet, having a DDNS or IP is the same.
OpenVNP secures your connection, but the risks are the same with DDNS or IP.

It should be just that, but actually when I activate DDNS I can access the router configuration interface, for example, by connecting to the domain name issued by the DDNS service; if, on the other hand, without having active the DDNS service, I try to access with the IP address (the one that the ISP entrusts me at that moment), the connection is refused (rightly I think). So it’s not the same. I think DDNS unblocks something at the firewall / port level and thus allows access from the outside, even for those who shouldn’t. So I am protected only by the LuCI password.

EDIT: Maybe it isn’t. I was only logging in because I was pointing to the IP address while connected to it. So on Turris ssh and reForis and LuCI only accept traffic from the LAN?

DDNS is nice feature, but personally when i used it, later on there were many attackers knockings on my router (so many attempts and failures during handshake init). I was a bit scared, but i found that those are almost harmless (without keys almost imposible to pass that handshake, usually within 30 sec they were kicked out no matter what).
I did not like that, so that is why I deactivated ddns service (it was due another issue at that time → update of TOS was failing due ddns service was up and running while it tried to update it … and stucked., or maybe just post-scripts were not able to finish properly)


So i think it is better to have some cron.d task checking the publicIP vs ip used by openvpn instance (if matching all fine, if different, restart the vpn and send new publicip via email to you (maybe send ovpn profile (encrypted of course)). I know it is not elegant (especially when on Android and using .ovpn inline config with official openvpn app …where you have to edit it elsewhere and re-import it). Personally i have dynamic ip as well, but it stays same almost all the time (in 4 years i’ve got new one when there was change in ipv4 pool and later when my isp was bought by bigger company).

config interface (reforis/foris/luci), the “lighttpd” should be accessible only within local or vpn networks. If you see foris/luci directly when using “ddns” name, you have something wrong in routing (firewall setup). By default vanila firewall setup, active haas or/and minipots should not cause that real service is exposed to public.

testing within local network

If you are testing openvpn within local network (cable or normal wifi), it might get confused with routing directives. Same applies when client-local network subnet is same as your openvpn-local network subnet (then routing became fuzzy, especially on windows clients → for that purpose you have change the config a bit “floating, clamping, fragmentation” stuff.). This “routing” became even more fuzzier, while DDNS is active.

I configured everything very simply. I purchased a domain on Google Domains (supports HTTPS, IPv6 and DNSSEC) and manually edited the client configuration file as you indicated. One question remains: the router is set up with IPv6-in-IPv4 via the Hurrican Electric service; i also set up a DDNS for the IPv6 address and it works perfectly. But if I enter the domain for IPv6 in the OpenVPN client configuration file I can’t connect because the server is unreachable. In the settings for the server I have enabled listening on IPv6. What did I miss?

EDIT: The network I’m trying to connect to the VPN from doesn’t support IPv6. But to take advantage of Omnia’s dual-stack?

… it depends … on many other stuff …hard to say. I am not using ipv6 at all. So not sure if can help more. Anyway Openvpn should work with IPv6 smoothly. So check if dhcp (main, openvpn) are using ipv6 and also “resolver”(unbound/kresd+dnsmasq) is resolving in ipv6 as well. If you use ipv6 instead of ddns name, is it working? (but if you have wan set for ipv6(or dualstack) , it should be already taken care of …by Foris/Luci). The only stuff maybe, do you have correct list-push directives in your openvpn server/client config(s).

This is functional example of such a script:

if [ ! -f "$file" ]; then
    # if not exist the file, create it
    echo "" > $file
    #echo "File was created"

value=$(ifconfig -a eth2 |grep 'inet addr' |cut -c 21-35 |sed 's/ .*//')
if [ "$value" != $(cat "$file") ]; then
    # update value in the file and send notification
    echo "$value" > $file
    create_notification -s news "Public IP: $value (valid from $(date +"%Y-%m-%d %T"))"
    #echo "Value was updated"

My setup (LuCI/ssh user here), on a native IPv4+IPv6 ISP:

  • DDNS using (actually using it to host a domain I own), both IPv4 and IPv6 addresses (2 DDNS configs); quite a few subdomains, and they’re set to update in unison
  • port tcp/22 (ssh) open in firewall, “accept input” (so ssh reaches the router)
    • ssh configured to allow routing ports to different hosts
    • I installed fail2ban too, for good measure
  • lighttpd configured for tcp/8080, disabled SSL (could set it to tcp/8443); not open in firewall
  • port tcp/80 (http) open in firewall, routed straight to a Synology box
  • port tcp/443 (https) open in firewall, “accept input”
  • haproxy runs a bunch of frontends, listening on different ports; backends correspond to stuff in my home net
  • sslh listens to tcp/443 only; if ssh traffic, gets routed to localhost:22, if cloudstation data pattern, gets routed to the synology box on the appropriate port; if https, depending on hostname, it’s routed to a specific port that haproxy listens to
  • openvpn configured for upd, ipv4+ipv6, port opened in firewall (accept input)
  • a couple more ports opened (ipv4+ipv6) and a bunch of socat’s to redirect ipv6 traffic to where I wanted it (like, [::]:6690 to 192.168.x.y:6690) - necessary since ipv6 allocation is somewhat… inconsitent across my stuff

End result:

  • if I need to ssh into, say, the esxi or the synology box, I ssh to my.domain and then ssh from the router to that box
  • if I need something simple, like RDP to a Windows VM, I generally just use ssh’s port forwarding, then connect to the port I opened on localhost
  • if I need something more awkward, like printing on the home printer, I just connect the VPN
  • most of the stuff in my home net I care about can be reached over https in two ways:
    • ( subdomain) lands on the router on 443, reaches sslh which, depending on svc, routes it to a specific haproxy frontend port (which further routes traffic to the relevant server)
      • examples: gets sent by sslh to port N of haproxy, the frontend of which uses unconditionally the http backend localhost:8080; gets sent by sslh to port M of haproxy, the frontend of which uses the https backend of mail:443; etc
      • if svc doesn’t exist, I simply forward to the web server on the synology box
    • my.domain https goes to a haproxy frontend that demuxes things, so they end up where they should
      • simple examples. accessing the router: a rule to send a redirect (http 301) my.domain/router to my.domain/cgi-bin/luci, plus one that sends every path starting with /cgi-bin/luci or /luci-static/ to the router backend. similarly, my.domain/vm is routed to my.domain/ui/, and everything starting with /ui/,/ticket/,/sdk,/dyndata.js,/screen gets sent to the esxi server
      • addresses that don’t match any of my rules get sent to the web server on the synology box
      • the reason I have both and my.domain/svc is that, while I prefer the later, I couldn’t mux all the services I wanted on it, because of conflicting paths

Btw, I know haproxy wasn’t meant for this, but hey. Wanting to do things like this is the reason why I got the Omnia in the first place; I tested all of this in my TP-Link WDR4300, but its performance sucked. So I did my research, figured I wanted some Linksys WRT device (except some people were complaining about the level of OpenWRT support), then figured Omnia existed.
Never looked back :slight_smile:

And sure enough, no part of this post is meant to badmouth/praise any router, service or software. It’s just a tale, which maybe highlights a silly, but NERD-POWER!, application, where the Omnia simply shines :slight_smile:

Hopefully this will give people a bunch of ideas >:)

EDIT: I’m too old-school to use Foris for anything except approving Omnia updates; also, I’ve a healthy suspicion of basically everything I don’t understand, so I try to stick to either stuff I can’t live without, or to stuff which I understand well enough. Configured openvpn using nano, simply because I knew how to do that by the time I discovered luci-app-openvpn existed; I won’t even mention Foris/reForis.

Also, if the above config confuses people: I’ve been in places where the network would restrict what ports you could connect to, outside it. Part of the sslh thing is, I get to ssh to my.domain:443 and it’ll work just fine, just like I can point the Synology Drive app on my phone to my.domain:443. Yeah, I know, poor security on their part, looking at the port not the packets, but hey, wasn’t me :smiley:
As for the URL muxer, I basically couldn’t figure how to do reverse proxying properly, and I really wanted to minimize the exposure my home net stuff got to the outside world. Which is basically why I tried the mux-a-single-domain approach - most hackers would hopefully go mental once they found that different URLs on my domain were handled by completely unrelated machines. You don’t ordinarily find, on the same IP, LuCI on lighttpd, an UPS network card, an ESXi server, an Exchange server and a few Web Station pages, some on nginx, some on apache - with no trace of proxy headers.

A huge setup, but I’m sure you have a great time. I only use OpenVPN, because once connected to Omnia I am practically catapulted into the home network, using a well-established and fairly secure protocol, so I can access all the functions and devices at home on the go. I just want to know how do you get OpenVPN over IPv4 and IPv6. Although I have IPv6 protocol selected in the server and client configuration file, and Omnia works on both protocols, once the connection is established, the client has only IPv4 address and not IPv6. Does it depend on the fact that the device I connect from is on an IPv4-only network (the device itself supports both protocols)?

It’s the same for me - even though I normally connect openvpn over IPv6, my client gets an IPv4 address. Doesn’t prevent anything from working though. Do you really need IPv6 over the VPN link?

No, I can actually do everything on IPv4 too. It’s just a desire to understand.

To be fair, I don’t fully understand all the quirks of IPv6 myself, and fortunately I didn’t have to, so far.
I’ve set up all my stuff with IPv4 in mind, with IPv6 just as a redundancy option (from outside the network, some devices - such as Android phones - seem to prefer IPv6 for some reason), which is why I have a bunch of socat’s redirecting IPv6 ports to IPv4 ones.

On the matter of IPv6 over OVPN, I can only conjecture that the client doesn’t bother configuring IPv6 on the TUN/TAP interface, and/or the server won’t care about IPv6 by default; I’m willing to bet it’s possible to do, but I expect in most cases there’s no need (which is a great argument in favor of IPv6 connectivity not being on by default).