|
From: Erich T. <eri...@th...> - 2026-03-31 15:36:20
|
Hi Mark Am 31.03.2026 um 14:44 schrieb LEAF: > Hi Erich, > > Quick update on today's play > > On 31/03/2026 9:53 pm, Erich Titl wrote: >> >> modprobe will not do this. I _believe_ most of the modules are loaded >> when you start shorewall, which itself calls mount_modules/ >> umount_modules to make the modules available. >> > I found if I modify the /etc/init.d/wireguard start function from: > > $WG_QUICK up $INTERFACE > > to: > > /usr/sbin/mount_modules > $WG_QUICK up $INTERFACE > /usr/sbin/umount_modules > > All the module names I had to add to /etc/modules for wireguard can go > away. As long as you don't run wg-quick directly on the first start and > always use the init.d script for this. If /etc/default/wireguard has > start set to Yes, this will just happen and load all the needed > wireguard modules. Right, so wireguard loads the modules dynamically. I am pretty sure it uses the same kernel modules as shorewall to handle iptables. > > Of course I needed to add /etc/init.d/wireguard in the local files list > so the changes get saved to configdb.lrp so they survive a reboot. > Maybe this change can be made to wireguard.lrp going forward by the LEAF > developers so this isn't necessary for others to do in the future. I would believe this is an easy modification which will not hurt. > >> I _guess_ in the "standard" set up LEAF is using shorewall as its >> iptables set_up utility. If your installation does not use this you >> may have to install the kernel modules yourself. Your method to add it >> to etc/modules might be inconvenient but most intuitive. >> > I'm using shorewall as well to handle the masquerading / SNAT of the > traffic from Mint VM through the router VM to the VPN link. Though I > haven't got that working yet. All traffic from the router VM to the VPN > link dies when shorewall is started, so I don't have something setup > right. But I did discover I have to use init.d scripts to start > shorewall in the first instance so the modules that shorewall needs get > loaded after a reboot instead of using "shorewall start" directly. My experience is/was that it is the safest way to start shorewall in any case. > >> >> Look above, I somehow guessed it. I believe once you have shorewall up >> and running your troubles will just disappear. >> > Except you need the wireguard link created before shorewall can use it > as far as I know. I'm not creating it via the interfaces file, so it > doesn't exist until wg-quick creates it. > > After all this, it would still be nice to have an openresolv.lrp so > future users don't have to make all the same discoveries and back them > up to configdb.lrp I still don't understand the openresolv issue. The way I understand it manages resolv.conf and apparently it allows applications to manage /etc/resolv.conf at will. If you are using dynamic addresses this ist done most of the time by your dhcp client process and you don't want to mess too much with it. For static addresses I see little advantage to just edit /etc/resolv.conf manually as basically it just uses a different notation and another configuration file to maintain. YMMV cheers ET -- „Wer von seinem Tag nicht zwei Drittel für sich hat, ist ein Sklave.“ ―Friedrich Nietzsche |