On Tue, 27 May 2014 18:24:41 +0200 berenger.mo...@neutralite.org wrote: > Hello list. > > I am trying to build a virtual network exposing servers accessible > from the LAN. > I have done a lot of searches on the web and it worked last week, but > since then, I have restarted my computer and had the nice surprise to > learn that the iptables command does not save it's configuration. > I tried to retrieve my configuration, but am failing ( I tried to > understand what I did with the history command, but sadly I am always > working with tons of terminals and so, I suspect that it is not the > correct history... ), and same to find anew the articles which > actually make things working. > > I had some network knowledge in the past, but never really practiced > it, so I have lost almost everything. I already have used some > firewalls, but those were some Windows ones ( I was not a linux user > at that time ) and so I have never played with iptables. > > So I ask for 2 things: > _ help on this particular problem > _ if someone knows about resources to learn and understand how > exactly iptables work, this would help me a lot in the future > Google will provide you with many thousands. The usual question arises as to which of them are up to date, there have been a few small changes in iptables, and some may rely on the sysv init system, which is fast disappearing.
As to the particular point you raise here, 'iptables' is a system command which adds (or subtracts or edits) one rule to the kernel firewall ruleset. A set of rules created with this command is not persistent, as you have found. There is a built-in iptables utility, iptables-save, which will save the current ruleset, and a restore command which can be run on boot. Debian also has the package iptables-persistent, which does just this. This package is relatively recent, and when I needed to address this problem, I had just built a Linux-From-Scratch system, so I took their init script skeleton and made a pseudo-daemon, entering a set of iptables commands at boot. This is an alternative approach, and may be more flexible, but requires work. It allows the use of alternative iptables rulesets, written as shell scripts, and therefore allows offline editing of the scripts and on-the-fly selection of them. On my mobile systems, I have two rulesets depending on whether I am in a (fairly) trusted network or a dodgy one, when I use a VPN to my home network and a more restrictive local firewall. There are also programs which will 'help' in setting up an iptables firewall, such as firestarter, but having started out by making my own iptables scripts, I found these programs too limited, and I think as you are doing non-standard things, you might also. I've got used to using iptables logging as a quicker and simpler way of solving (some) networking problems than a packet analyser, and to do this requires complete control over the ordering and construction of rules. > For my particular problem. > Sorry about this, routing to VMs can offer unexpected challenges, and I haven't used any with any routing complexity for a few years, so I can't help much. The only VM I currently use does NAT. As I recall, broadly, to avoid NAT, the VM must use a bridging network connection (virtualbox does either easily) and the VMs must therefore have IP addresses compatible with the TCP/IP settings of the real NIC, in other words they must be set up as if they are real machines on the same network as the host. I vaguely recall setting up the real NIC as a br0 interface rather than eth0, plus a bit more tweaking. I think. It is some time since I did this, and there is no remaining evidence. [Further disclaimers as required]. It is also possible that the virtualbox system does more to help now. Oh, yes, if IPv6 is allowed into your network, there is also an ip6tables, which is completely independent of the v4 system, and by default allows anything anywhere. I currently have no use for v6, so I've just added drop policies to my main ruleset, and that seems to work. -- Joe -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140527231350.7c130...@jretrading.com