Re: [Shorewall-users] IP address change not surviving reboot

[Bruce B. <bru...@gm...>]

Hello Philip,

I suggest that you go back and review your network setup to double check where your IP address and routes are defined. 

On many Debian based Linux distributions interface setup is typically defined at /etc/network/interfaces. This file may sometimes be used to define routes for an interface. There is a man page that may be of use, try the command: man interfaces.

This /etc/network/interfaces file is what is typically used by Linux to allocate your IP address at boot time. 

If you’re getting different IP addresses at boot, it may be because your server is configured to use DHCP to request the allocation of an IP address from a pool of available addresses.

Shorewall uses the network and routing settings that you define for your server in your server configuration files, like /etc/network/interfaces. Shorewall does not define IP addresses and routes for you.

Some other useful commands are (assuming a modern linux distribution which I expect that you have noting your interface name of enps20):

ip address show
ip route show

If you are unfamiliar with these commands view the relevant man page.

Kind regards,

Bruce
 

> On 17 Aug 2023, at 19:07, Philip Le Riche via Shorewall-users <sho...@li...> wrote:
> 
> Not getting very far with this on the Linux Mint forums - it seems like an IP address change most certainly should survive a reboot, and it seems implausible that such a blatant bug would go unnoticed on a standard set-up.
> 
> But Shorewall isn't a standard set-up (quite). A germ of an idea is forming.
> 
> I'm using rules in /etc/shorewall/nat to do 2-way natting between Raspberry Pi local addresses and external addresses on the school network, and I set ADD_IP_ALIASES=Yes in shorewall.conf.
> 
> I suspect what's happening is that I'm getting into a situation where enp2s0 has an IP address on one subnet and enps20:0-16 created by Shorewall are on a different subnet, and that the confusion is causing a new enp2s0 to be created on rebooting.
> 
> The solution would seem to be to turn off the start-on-boot option in shorewall.conf, reboot, do everything needful with the IP configuration, reboot to make sure it sticks, and only then allow Shorewall to start.
> 
> I won't be able to try it until Monday at the earliest, but it sounds like there's a subtle mantrap here that could perhaps be highlighted in the docs.
> 
> But why does it seem to take 25 seconds to create the NAT aliases? Is this to be expected?
> 
> 
> 
> On 15/08/2023 22:02, Philip Le Riche wrote:
>> Thaks Matt - 
>> 
>> On 15/08/2023 15:56, Matt Darfeuille wrote: 
>>> On 8/15/23 15:44, Philip Le Riche via Shorewall-users wrote: 
>>>> We have a Shorewall firewall at the school where I volunteer, protecting the school network from a Raspberry
>> snip... 
>>>> by Shorewall for NAT rules. Meanwhile, a new enp2s0 has appeared with an IP address I didn't recognise. 
>>> 
>>> This is a wild guess, to me you have a static network at home and a DHCP set up at school. :) 
>> But that wouldn't be representative of the school environment, and I'm not sure how the NAT addresses could be made dynamic. You only need to be clever enough to avoid the DHCP pool to allocate a static address. And I was fortunate that I could use the same 4th octet in both environments and hence capture the Shorewall dependencies in my params file. 
>>> 
>>>> 
>>>> ifconfig shows the base enp2s0 with no IP address, plus the 16 expected
>>> 
>>> With a new set up, I would familierize myself with the iptools PKG! ;^) 
>> ifconfig has served me well since SysV. Hey ho. Maybe I have to move with the times. 
>>> 
>>>> shorewall stop and shorewall clear before reapplying the config made no improvement. 
>>>> 
>>> 
>>> Most likely because it has nothing to do with SW! 
>> Most likely. 
>>> 
>>>> Maybe I should be using the CUI commands, but I'll need to read a man page or two first, and I'm not sure whether the GUI tool maintains any of its own data. Anyway, a bit of insight from round here would be appreciated. 
>>>> 
>>> 
>>> To me , headless mode is the way to go (Webmin comes to mind). 
>>> 
>> For a server shut away in the basement that sounds like a good option. Must check it out. Except that I'd have had to successfully change the IP address before I could access Webmin (to change the IP address). And for a firewall, it'd add significantly to the attack surface. A quick search for "webmin cve" listed 81 vulnerabilities. 
> 
> _______________________________________________
> Shorewall-users mailing list
> Sho...@li...
> https://lists.sourceforge.net/lists/listinfo/shorewall-users