Discussion in 'Tomato Firmware' started by Mechelle, Mar 2, 2019.
Is there a way to change tun11 to tun0?
What is a tun?
Is this in relation to OpenVPN? If so, add:
In the custom config section of the GUI.
If not using OpenVPN, then use ifconfig to manipulate and manage interfaces.
Yes, this is in relation to OpenVPN.. thank you! I will try it.
Be careful changing the OpenVPN network interface name. It's very likely that other parts of the system are assuming tun11, for example, the automatically generated firewall rules! IOW, just because you changed "dev tun11" to "dev tun0" doesn't mean the GUI will necessarily respect that change and propagate it throughout the rest of the system.
While I haven't gone through the code relating to OpenVPN, init ( rc ) should be checking NVRAM for user entries into the custom config box and avoid overruling or conflicting configurations, the same as it does for dnsmasq. If found that this isn't the case, a bug report should be made, as providing a custom config entry method with no mechanism for conflict avoidance is bad design.
It doesn't, and as far as I know doesn't do any parsing of the custom config for dnsmasq either - at least not in my experience.
Tomato creates tun21/tun22 for server1/server2 and tun11/tun12 for client1/client2.
I don't have any tomato ovpn clients running, but it looks like adding a "dev tun0" entry to a server config will cause OpenVPN to create both a tun0 and a tun21, OpenVPN gives the IP to the last entry (tun0) and tun21 is orphaned. Generated iptables rules are for tun21, but setting firewall=custom in the gui and writing custom rules should work.
I think the devs would likely use a separate gui entry if they wanted to support custom interfaces. Then they would also have to parse any potential conflicts between server1/server2/client1/client2 and tinc.
All doable, but more of a feature request than bug report.
An input box labeled "Custom config" should, by design, anticipate the allowed configuration directives of the program it is intended for. If not, then individual options that are compatible with the firmware should be itemized and listed for user selection. It makes no sense to say "Put your custom config here" when really it means "Put your custom config here, however some options may collide with ours, we don't know which ones but you can't turn ours off anyway".
My bad on Dnsmasq, I meant to say Samba. Myself and Koitsu patched that bug years ago, by separating out the interface option into its own selection ( same as I said above should be done if directives can cause conflicts ) and tested by RC upon init, as prior to that a custom interface directive would conflict with the firmware and cause Samba to bind to everything, including the WAN.
**NOTE** Dnsmasqs config is indeed checked, at least to some degree, for conflicts against user input. Here are a couple commits specifically relating to it:
I don't think either of the examples are parsing the dnsmasq custom config unless they have been put back post shibby and enhanced.
Shibby took a patch removing cache size from the command line and moving it into the config file. This was undone on the next revision because it broke previously running setups.
The config file could override the command line, but two cache-size entries in the config file (no parsing was being done) broke dnsmasq.
Folks that had cache-size already defined in custom had inoperable routers when they flashed the first update.
dnsmasq config directives are a mess with some duplicates being additive, some breaking dnsmasq, and some being last entry wins.
I agree, that in general, processes like OpenVPN and DNSMasq should (and usually do) respond accordingly to changes in their respective configuration files. But the example I gave w/ the firewall rules being affected is a special case. The OpenVPN process itself knows *nothing* about firewall rules. The addition of firewall rules (which use the device name) are outside the immediate scope of the OpenVPN process. The only way a change in the device name will be respected when it comes to the firewall rules is if the tomato developers anticipated this happening and went to the trouble to detect the change in the device name in the configuration. In my experience w/ most third party firmware, this is highly unlikely.
In fact, this is one of the reasons that you're *supposed* to use the OpenVPN scripting engine to add firewall rules. The scripting engine passes environment variables to your script that contain the current and correct value of various settings, including the device name. Had the OpenVPN implementation on tomato used the scripting engine and the "dev" environment variable to determine the actual device name, this problem wouldn't exist. But instead, once the OpenVPN process is started, tomato blindly implements its firewall rules based on tun11.
So again, I'm not talking about simple configuration file changes that affect the immediate process (OpenVPN, DNSMasq, etc.). I'm talking about changes that have more of an arm's length relationship w/ those processes, like the firewall.
FWIW, I just tried connecting to an OpenVPN server using "dev tun0" in the configuration section (FreshTomato Firmware 2018.5 K26ARM USB AIO-64K), and as I suspected, a dump of the firewall still shows "tun11" being used by the firewall rules.
I don't know about that. We have a "custom" firewall option in the GUI for a reason, A lot of folks (including me) want finer control - but Tomato assumes if the user goes the custom route they know what they are doing. I always thought the default rules were poorly placed and far too open for my needs.
If OpenVPN's processing of multiple dev entries is consistent, then if a user wants to use a specific device name - specify the dev in custom config, set firewall to custom (or possibly external for a server), add appropriate rules to the firewall script, and optionally specify an up script with "ifconfig tun11/12/21/22 down" to remove the orphaned tun interface for paranoia's sake.
My point was not that it does or does not parse the configuration file specifically, my point was that steps have been taken to avoid conflicts of custom config inputs and firmware defaults. Whether that's putting the options that cause issues into their own selection category, parsing the config files, or whatever method makes one happy.. as I stated previously:
When a valid config parameter of a process is used and not respected by the firmware, ( IE: the only reason a problem occurs is because the firmware does not allow the users config to override its own) it's a bug.
In this case however, I didn't realize OpenVPN's configuration actions weren't all inclusive, as @eibgrad pointed out, the scripting engine is not used.