I have an environment where I have openvpn and shorewall on the same
node. Given that I want different rules applied based who the peer is
and given that IP addresses given out by openvpn can be different from
time to time (I don't want to get into statically allocating addresses
as peers come and
Brian J. Murrell wrote:
I have an environment where I have openvpn and shorewall on the same
node. Given that I want different rules applied based who the peer is
and given that IP addresses given out by openvpn can be different from
time to time (I don't want to get into statically allocating a
Brian J. Murrell wrote:
> I have an environment where I have openvpn and shorewall on the same
> node. Given that I want different rules applied based who the peer is
> and given that IP addresses given out by openvpn can be different from
> time to time (I don't want to get into statically alloca
On Mon, 2008-09-08 at 14:57 -0700, Tom Eastep wrote:
> Define the rules in terms of dynamic zones (preferably defined using ipsets
> rather than the deprecated DYNAMIC_ZONES=Yes), then simply add an address to
> the appropriate set when the client logs on and remove it from the set when
> the cl
Brian J. Murrell wrote:
I did take a peek at dynamic zones. Just to be sure I understand
completely, if every one of my peers had different rulesets, I'd need a
dynamic zone for each peer, yes? Are there any scaling issues
associated with having a lot of dynamic zones?
The complexity of the
On Mon, 2008-09-08 at 14:57 -0700, Tom Eastep wrote:
>
> Define the rules in terms of dynamic zones (preferably defined using ipsets
> rather than the deprecated DYNAMIC_ZONES=Yes),
Giving this a go, I found a couple of things:
* WARNING: SAVE_IPSETS=Yes is not supported by Shorewall-perl
Brian J. Murrell wrote:
On Mon, 2008-09-08 at 14:57 -0700, Tom Eastep wrote:
Define the rules in terms of dynamic zones (preferably defined using ipsets
rather than the deprecated DYNAMIC_ZONES=Yes),
Giving this a go, I found a couple of things:
* WARNING: SAVE_IPSETS=Yes is not support
On Mon, 2008-09-08 at 16:41 -0700, Tom Eastep wrote:
>
> Shorewall has nothing to do with set creation or maintenance.
I wonder what the philosophical problem is with Shorewall creating an
empty ipset if one doesn't exist already.
Certainly I could put commands into the "init" (I think that woul
Brian J. Murrell wrote:
On Mon, 2008-09-08 at 16:41 -0700, Tom Eastep wrote:
Shorewall has nothing to do with set creation or maintenance.
I wonder what the philosophical problem is with Shorewall creating an
empty ipset if one doesn't exist already.
Certainly I could put commands into the "i
On Mon, 2008-09-08 at 16:50 -0700, Tom Eastep wrote:
>
> I'm not spending one minute on any new ipset functionality until ipsets are
> a part of official kernel.org kernels. And I'm not going to spend any time
> discussing the issue either.
Fair enough. I just got the impression that you were
Brian J. Murrell wrote:
Fair enough. I just got the impression that you were (in a previous
message) promoting ipsets as if they were the way to go and the way
Shorewall was heading in terms of future direction.
I think that ipsets are the greatest thing since sliced bread -- I just wish
tha
So, I think I almost have it but for whatever reason I'm not getting my
loc2vpn1 (where vpn1 is a dynamic zone) rule high enough in the _fwd
chain:
Chain br-lan_fwd (1 references)
pkts bytes target prot opt in out source destination
2005 167K dynamicall
On Mon, 2008-09-08 at 17:19 -0700, Tom Eastep wrote:
>
> I think that ipsets are the greatest thing since sliced bread -- I just wish
> that the Netfilter team would get off of their collective asses and get
> ipsets into the mainstream.
Heh. Now, that I cannot argue with. :-)
b.
signatur
Brian J. Murrell wrote:
What governs the order of the rules that go into the _fwd tables and how
can I get the loc2vpn1 rule assessed higher than the loc2all(tun0) rule?
man shorewall-zones
-Tom
--
Tom Eastep\ Nothing is foolproof to a sufficiently talented fool
Shoreline, \ http://s
On Mon, 2008-09-08 at 20:01 -0400, Brian J. Murrell wrote:
>
> I will try to write some combination of extension scripts to do this
> part automatically. If all else fails, I will just list my ipsets in a
> simple extension script.
Again, for the current and future followers of this thread here
On Mon, 2008-09-08 at 23:14 -0400, Brian J. Murrell wrote:
> here is the
> compile script (for Shorewall-perl)
I hate it when I do this, but here's the cleaned up version...
cut
use File::Temp qw/ tempfile tempdir /;
print "Finding used ipsets\n";
my @ipsets;
open(HOSTS, "hosts") ||
Brian J. Murrell wrote:
On Mon, 2008-09-08 at 23:14 -0400, Brian J. Murrell wrote:
here is the
compile script (for Shorewall-perl)
I hate it when I do this, but here's the cleaned up version...
Which assumes that the only type of ipset worth creating is iphash --
beware.
-Tom
--
Tom Easte
On Mon, 2008-09-08 at 20:32 -0700, Tom Eastep wrote:
>
> Which assumes that the only type of ipset worth creating is iphash --
> beware.
Indeed.
As an aside, by the time the compile script is executed, have all of the
config files been opened and their data enumerated into perl vars? i.e.
coul
Brian J. Murrell wrote:
On Mon, 2008-09-08 at 20:32 -0700, Tom Eastep wrote:
Which assumes that the only type of ipset worth creating is iphash --
beware.
Indeed.
As an aside, by the time the compile script is executed, have all of the
config files been opened and their data enumerated into p
Tom Eastep wrote:
Brian J. Murrell wrote:
On Mon, 2008-09-08 at 20:32 -0700, Tom Eastep wrote:
Which assumes that the only type of ipset worth creating is iphash --
beware.
Indeed.
As an aside, by the time the compile script is executed, have all of the
config files been opened and their dat
20 matches
Mail list logo
