Re: iptables, virtualbox and port forwarding
On Tue, 27 May 2014 18:24:41 +0200
berenger.morel@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
Reply to: