From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Firewall Question
Date: Wed, 17 Oct 2012 12:08:43 +0200 [thread overview]
Message-ID: <1350468523.9815.56.camel@rice-oxley.tremer.info> (raw)
In-Reply-To: <5079AABC.4020104@oab.de>
[-- Attachment #1: Type: text/plain, Size: 2490 bytes --]
On Sat, 2012-10-13 at 19:54 +0200, Alexander Marx wrote:
> Am 13.10.2012 19:18, schrieb Michael Tremer:
> >> I already tried to play with the OVPNFORWARD Chain but had no luck.
> > You should use CUSTOMFORWARD/CUSTOMINPUT for those rules.
> ok. But why are there the chains OVPNINPUT and OVPNFORWARD?!
> As far as i understand right now, these chains should be DROP ore
> flushed, when Firewall is in mode 1, right?
> And to think a bit further, when someone begins to develop an addon or
> core function to create rules
> for CUSTOMFORWARD with a webgui, is this sufficient for creating a
> INCOMING Firewall?! (I know its FORWARD-Chain)
> But i hope you understand what i mean.
Those chains have been introduced with the OpenVPN addon.
It was intended to build in-tunnel filtering, but that has never been
implemented.
If you would like to implement filtering for VPN tunnels, please use
those chains. Don't put anything into CUSTOM* because these are for
rules that are manually created by the user.
OVPNINPUT and OVPNFORWARD work in exactly the same way. Same for
IPSECINPUT and IPSECFORWARD.
> >> It would be great if one can say:
> >> Hey, VPN1 is only allowed to connect to my internal servers 192.168.0.2
> >> and 192.168.0.3 via RDP (3389)
> >> ans that via gui
> > You can use the outgoing firewall to limit some sorts of traffic, but
> > you cannot block incoming packets with it.
> >
> >> I already developed addons for ipcop, but ipfire seems complete different...
> > No, the web UI is pretty much the same (crap). The firewall scripts do
> > not differ too much, either.
> Well the way ipfire is compiled and the way addons are created is much
> more complicated at a first sight.
Indeed, there is a detailed guide how to start on our wiki.
http://wiki.ipfire.org/en/development/build
> If i would understand how to add changes to the ipfire, maybe i would
> begin to develop some sort of
> gui for creating some firewall-rules.
> I think it is not so difficult, because it just takes a textfile for the
> rules, and a table in webinterface where the rule positions can be
> changed and created. And a funvtion, that reads the rules on every reboot.
>
> Do you agree so far?!!
Yes, that's the way.
Maybe it is a good idea to integrate that as native as possible into the
WUI, because there already too many possibilities how to add firewall
rules (portfw, xtaccess, outgoing firewall,...).
Michael
next parent reply other threads:[~2012-10-17 10:08 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5079AABC.4020104@oab.de>
2012-10-17 10:08 ` Michael Tremer [this message]
2012-10-13 12:39 Alexander Marx
2012-10-13 17:18 ` Michael Tremer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1350468523.9815.56.camel@rice-oxley.tremer.info \
--to=michael.tremer@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox