I'm running openwrt 24.10.1 on a Vbox VM, and have been doing so for several years without too many issues. About a year ago, I decided to add a VPN, and for the most part, it has also worked fairly reliably. But getting an address every time is unreliable.
I have a half-dozen VPN servers configured on my openwrt (and the corresponding devices are "configured" in the devices tab), and I have selected a specific tunnel (device) corresponding to one of those in my VPN interface. (NB: I define specific tunnel devices for each VPN server rather than "tun0," "tun1," etc., to make them easily distinguishable). Upon initial boot, openvpn works as expected, getting an IP address from the VPN's DHCP server the connection on the VPN interface/device.
However, if I decide to switch to a different server by changing the VPN device associated with the VPN interface, that interface does not get a DHCP lease/address even after several minutes. I have tried restarting network, firewall, openvpn, and some others just to see if I could coerce the interface to fetch a new lease. (EDIT: tcpdump does show DHCP requests going out but no replies.) So far, I have come up empty. The only thing that seems to work is to reboot the router.
Rebooting does not take long, and it usually gains a new lease (but not always, even with a reboot). It's mainly the nuisance about having to do this, and not understanding why I must reboot to get the new configuration to work. I hope someone can explain possible reasons which could lead to a solution.
I change the VPN device by selecting the desired tunnel device (associated with a particular VPN server/configuration) in the interface, saving it, and even manually restarting the interface (although I expected that that would be done by the system itself already; just to make sure).
All of this is done via LuCI, not uci and not by editing the /etc/config files. However, this should not make a difference, assuming manual editing or uci calls were done correctly. I find the LuCI more convenient and less prone to me causing config mismatches, at least until I am knowledgeable about various aspects of the configuration files.
Yes (see my OP). And firewall and openvpn as well. To be really thorough, I even ran stop and start separately for each; sometimes stop-then-start commands work better than restart/reload commands on other types of systems.
Maybe that is the culprit, if you have all your traffic routed via the VPN then if you want to switch you just stop one VPN tunnel and start another.
Note that you can use Policy Based Routing to route different LAN clients to different VPN tunnels
It can also help if you show us your configs, in that case please connect to your OpenWRT device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact keys, passwords, MAC addresses and any public IP addresses you may have:
ubus call system board
cat /etc/config/network
cat /etc/config/firewall
ip route show
In case you are using WireGuard as VPN also show:
wg show
In case you are using OpenVPN please show:
for ovpn in $(ls /etc/openvpn/*.ovpn);do echo $ovpn; cat $ovpn; echo;done
I was not receiving notifications from the forum so I did not see your reply until I checked the forum today. I have supplied the info you requested and I removed the long keys since they might be sensitive (idk) and take up space that is probably not useful.
As far as the router config w/r/t virtualbox, all of the NICs are configured for full promiscuity ("Allow All") and they are connected with the correct vbox networks. I can hit the Internet without a problem. It is only when I try to muck with the openvpn config/server after boot up (as I described in my OP) that problems arise.
I am not using policy-based routing at this point, although I might try that in the future. For now, I just want to achieve the freedom to switch VPN servers on the fly--without rebooting--in case of some issue or another. I have checked for dns leakage also.
This does not look right, you do not need anything of this as OpenVPN setups its own devices.
It is good practice to add an interface with a device associated (which is the device name from the OpenVPN config) which you can then use for firewall and e.g. PBR so it should look like:
config interface 'vpn5748t'
option proto 'none'
option device 'tun5748t'
config interface 'vpn9637t'
option proto 'none'
option device 'tun9637t'
config interface 'vpntun9663t'
option proto 'none'
option device 'tun9663t'
proto is always 'none'
Add all the newly created interfaces to your VPN firewall zone.
I did not check the rest of your settings but start with this
I didn't create those devices; they were created by openvpn or one of the system programs. Unless somehow some step I alone took along the way triggered their creation, but I don't recall anything specifically. The only "step" I can think of is when I configured (in the devices tab for) the devices which were already created by openvpn.
And my one interface for the VPN is already in the VPN firewall zone.
All of the VPN servers I have defined are ultimately in the VPN firewall zone because the one interface I have defined for VPN is in the VPN firewall zone. Again, there is only one interface for VPN.
OK well there is a difference between a device and an interface, see:
You have added all three devices to the VPN firewall zone which is fine as nowadays you can add a device. In this case there is no need to have anything regarding VPN in the interface section
In my example I do create VPN interfaces with proto none and then add a device, this can be useful for other things which you want to do with the interface in that case you add the three interfaces to the VPN zone (which causes the corresponding devices to be added)
You are now mixing things which makes it unnecessary complicated in my opinion although it can work of course.
I'm not sure what you mean. An interface requires a device, doesn't it? Is there some trick you are using to run an interface without associating a device to it?
What is it I am mixing? Sorry I am not following what you are saying. It is the interface, not the device, that is associated with the firewall zone. BTW, all of this comes from the wiki page on setting up VPN on openwrt, which per NordVPN's site, was developed by people on the openwrt project. I think I have followed the steps faithfully, but it could be that there have been some changes to openwrt since that wiki page was written.
In recent versions these stub interfaces are no longer needed. Their only function was to attach an Interface name to a Device, since the firewall config only recognized Interface names. Now the firewall has a new option list device which allows Devices to be placed directly into firewall zones.
OpenVPN in tun mode (being a layer 3 VPN) cannot send dhcpv4 through the tunnel as that involves making layer 2 broadcasts. OpenVPN server pushes the client address out of band as part of the connection handshake. The OpenVPN client then applies the IP to the tun interface as it creates it.
