What's new

Voxel Voxel R9000 OpenVPN to network .100 and port 443

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Selcal

Occasional Visitor
Hi all,

Using Voxel's firmware on the R9000, since V1.0.4.47 and the last before (I think, could be a bit longer) updates, I've run into an issue with the OpenVPN server.
The LAN runs on 192.168.3.xxx, and I have a device on .100

Clients connected through the VPN (tap) cannot make a connection to this .100 device, not even a ping. Connecting to any other devices works fine (.110, .92), just this .100 device! It's got me confused :). AFAIK the openVPN server doesn't run on .100 does it? Anything else that could cause this? I could move the device but several others on the network connect to it so it'd be a bit of doing. Surely it's a simple configuration thing somewhere :).

And on the openVPN subject, I'd prefer to run the server on port 443. Currently, this doesn't work. I read that this is a Netgear limitation (conflict with their hard coding of the router interface I guess), but perhaps with Voxel it's possible to fix this? I couldn't find anything on it.

Oh, and just curiosity, but offtopic, I couldn't find this in the changelog, but what happened to the HW builds? No benefit anymore?

Thanks again!
 
Clients connected through the VPN (tap) cannot make a connection to this .100 device, not even a ping.
Tap, so the VPN client also has an IP address from the 192.168.3.xxx range?

I'm not so familiar and only use tun -> in that case the clients would have an IP from a different range. And then it could also have been a firewall on the .100 device, that only accepts traffic from the local subnet.

And on the openVPN subject, I'd prefer to run the server on port 443. Currently, this doesn't work. I read that this is a Netgear limitation (conflict with their hard coding of the router interface I guess), but perhaps with Voxel it's possible to fix this? I couldn't find anything on it.

Can't speak for sure, but on R7800 the internal webserver (uhttpd) is listening on port 80 and port 443 -> this is why OpenVPN cannot listen there.
On R7800 a solution could be to change uhttpd config listen for https on a different port.
SSH into the router, edit /www/cgi-bin/uhttpd.sh and change 0.0.0.0:443 to for instance 0.0.0.0:8443
Then restart uhttpd via www/cgi-bin/uhttpd.sh restart
And after this, you could change OpenVPN server to listen on 443.
(disclaimer, no clue what might break by changing the https GUI to a different port.)

Perhaps this also works on R9000
 
Tap, so the VPN client also has an IP address from the 192.168.3.xxx range?

I'm not so familiar and only use tun -> in that case the clients would have an IP from a different range. And then it could also have been a firewall on the .100 device, that only accepts traffic from the local subnet.

Correct, it's on the same subnet. It's weird, this configuration has worked for ages. I doublechecked the firewall on the receiving machine, but nothing should block the VPN client (which as you say is on 192.168.3.xxx as well).

Not to worry; it's probably more simple to just change this machines IP and be done with it :). Unless something comes to mind!

Can't speak for sure, but on R7800 the internal webserver (uhttpd) is listening on port 80 and port 443 -> this is why OpenVPN cannot listen there.
On R7800 a solution could be to change uhttpd config listen for https on a different port.
SSH into the router, edit /www/cgi-bin/uhttpd.sh and change 0.0.0.0:443 to for instance 0.0.0.0:8443
Then restart uhttpd via www/cgi-bin/uhttpd.sh restart
And after this, you could change OpenVPN server to listen on 443.
(disclaimer, no clue what might break by changing the https GUI to a different port.)

Perhaps this also works on R9000
Cool, I'll try that on my R9000, will let you know what happens!
 
Can't speak for sure, but on R7800 the internal webserver (uhttpd) is listening on port 80 and port 443 -> this is why OpenVPN cannot listen there.
On R7800 a solution could be to change uhttpd config listen for https on a different port.
SSH into the router, edit /www/cgi-bin/uhttpd.sh and change 0.0.0.0:443 to for instance 0.0.0.0:8443
Then restart uhttpd via www/cgi-bin/uhttpd.sh restart
And after this, you could change OpenVPN server to listen on 443.
(disclaimer, no clue what might break by changing the https GUI to a different port.)

There is such an option in OpenVPN "port-share" allowing to share e.g. 443 port with Web Server. I tried it with my PC (OpenVPN server) but did not test with routers... Probably this it working.

Voxel.
 
  • Like
Reactions: KW.
There is such an option in OpenVPN "port-share" allowing to share e.g. 443 port with Web Server. I tried it with my PC (OpenVPN server) but did not test with routers... Probably this it working.

Voxel.
I've seen this being mentioned in the past as well. But I thought it would only work with more advanced webservers, like nginx or apache and depend on some mod-proxy configurations.

But apparently is is surprisingly simple. You still need to change the https port of uhttpd as I explained above, to for instance 8443.
And then you'd need to make sure that the OpenVPN server configuration contains:

proto tcp
port 443
port-share 127.0.0.1 8443


(of course on this firmware that would mean editting the file that generated the openvpn-server config (/etc/init.d/openvpn) )

I did not test this myself though.
Als I'm already forwarding 443 to my NAS.
(I guess port-share <ip-of-NAS> 443 could be an option, but then the downside is that all traffic arriving on the web-server of my NAS would appear to come from my router -> this would mess up logging and some access rules)
 
I've seen this being mentioned in the past as well. But I thought it would only work with more advanced webservers, like nginx or apache and depend on some mod-proxy configurations.

But apparently is is surprisingly simple. You still need to change the https port of uhttpd as I explained above, to for instance 8443.
And then you'd need to make sure that the OpenVPN server configuration contains:

proto tcp
port 443
port-share 127.0.0.1 8443


(of course on this firmware that would mean editting the file that generated the openvpn-server config (/etc/init.d/openvpn) )

I did not test this myself though.
Als I'm already forwarding 443 to my NAS.
(I guess port-share <ip-of-NAS> 443 could be an option, but then the downside is that all traffic arriving on the web-server of my NAS would appear to come from my router -> this would mess up logging and some access rules)

Having changed the port in uhttpd, it already worked. Port share was not required, at least not in my case. :)
I also tried port share on 443 (with the uhttpd also on 443) but this didn't work. Just as an experiment!
 
As for the issue connecting to the one PC on the network... I have a solution which makes absolutely no sense, but I share it as who knows could be helped:

First of all, I tried:
  1. Change IP to dynamic
  2. Change IP to different static
  3. Change OS (boot into Linux, Windows 7, Windows 10)
  4. Change switch connected to (all LAN though)
Monitoring the traffic, the .100 device could see the multicast requests, but no communication was coming or going between the VPN and this machine.

I then started playing a LOT with OpenVPN config on both sides. When none of the options that would've made ANY sense were exhausted, I went for simply commenting one-by-one. And found it.

The problem is solved by changing compression to lz4, instead of lz4-v2 (on both sides).
The solution is consistent across different configurations. It fixes/breaks every time on this point.

How? I have no clue. No errors are in the logs on any machine including the VPN server. I can't find any reason for this. But it is the solution in my case.
So far-fetched, that I wanted to share. Who knows who it might help!
 
Thank you for the information!

A side note is that compression and OpenVPN is not recommended at all:
https://community.openvpn.net/openvpn/wiki/VORACLE

As for the issue connecting to the one PC on the network... I have a solution which makes absolutely no sense, but I share it as who knows could be helped:

First of all, I tried:
  1. Change IP to dynamic
  2. Change IP to different static
  3. Change OS (boot into Linux, Windows 7, Windows 10)
  4. Change switch connected to (all LAN though)
Monitoring the traffic, the .100 device could see the multicast requests, but no communication was coming or going between the VPN and this machine.

I then started playing a LOT with OpenVPN config on both sides. When none of the options that would've made ANY sense were exhausted, I went for simply commenting one-by-one. And found it.

The problem is solved by changing compression to lz4, instead of lz4-v2 (on both sides).
The solution is consistent across different configurations. It fixes/breaks every time on this point.

How? I have no clue. No errors are in the logs on any machine including the VPN server. I can't find any reason for this. But it is the solution in my case.
So far-fetched, that I wanted to share. Who knows who it might help!
 
Good point, somewhere much further down on my todo list, I had a plan to test performace / throughput with and without compression to balance risk / benefit. But now... I guess off is better :).

Thanks!
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top