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 go) I''ve been cooking up something to make this work.
Essentially what I have is openvpn creating chains and installing rules
in them in the learn script with such stanzas:
if [ "$OP" = "add" ]; then
iptables -N "${CN}2loc"
iptables -I vpn2loc -s $ADDRESS -j "${CN}2loc"
iptables -N "loc2${CN}"
iptables -I loc2vpn -d $ADDRESS -j "loc2${CN}"
case "$CN" in
"brian-laptop")
iptables -I "${CN}2loc" -p udp --sport
4569 --dport 4569 -j ACCEPT
iptables -I "${CN}2loc" -p udp --sport
123 --dport 123 -j ACCEPT
;;
"peer1")
iptables -I "loc2${CN}" -s 10.75.22.1
-j ACCEPT
;;
esac
else
if [ -n "$CN" ]; then
iptables -D vpn2loc -s $ADDRESS -j "${CN}2loc"
iptables -F "${CN}2loc"
iptables -X "${CN}2loc"
iptables -D loc2vpn -s $ADDRESS -j "vpn2${CN}"
iptables -F "vpn2${CN}"
iptables -X "vpn2${CN}"
fi
fi
Where CN is the openvpn name for a peer, normalized to work well in
iptables rule names.
This appears to be working pretty well with some obvious caveats:
* goes to hell in a handbasket if shorewall needs to be restarte
* rules are in the learn script
* probably more caveats
Any thoughts on how to roll this more properly into shorewall so that
rules are specified with the traditional rules syntax and that it
survives restarts?
Cheers,
b.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer''s
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
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 addresses > as peers come and go) I''ve been cooking up something to make this work. > > Essentially what I have is openvpn creating chains and installing rules > in them in the learn script with such stanzas: > > if [ "$OP" = "add" ]; then > iptables -N "${CN}2loc" > iptables -I vpn2loc -s $ADDRESS -j "${CN}2loc" > iptables -N "loc2${CN}" > iptables -I loc2vpn -d $ADDRESS -j "loc2${CN}" > case "$CN" in > "brian-laptop") > iptables -I "${CN}2loc" -p udp --sport 4569 --dport 4569 -j ACCEPT > iptables -I "${CN}2loc" -p udp --sport 123 --dport 123 -j ACCEPT > ;; > "peer1") > iptables -I "loc2${CN}" -s 10.75.22.1 -j ACCEPT > ;; > esac > else > if [ -n "$CN" ]; then > iptables -D vpn2loc -s $ADDRESS -j "${CN}2loc" > iptables -F "${CN}2loc" > iptables -X "${CN}2loc" > iptables -D loc2vpn -s $ADDRESS -j "vpn2${CN}" > iptables -F "vpn2${CN}" > iptables -X "vpn2${CN}" > fi > fi > > Where CN is the openvpn name for a peer, normalized to work well in > iptables rule names. > > This appears to be working pretty well with some obvious caveats: > > * goes to hell in a handbasket if shorewall needs to be restarte > * rules are in the learn script > * probably more caveats > > Any thoughts on how to roll this more properly into shorewall so that > rules are specified with the traditional rules syntax and that it > survives restarts?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 client logs off. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
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 addresses > as peers come and go) I''ve been cooking up something to make this work. > > Essentially what I have is openvpn creating chains and installing rules > in them in the learn script with such stanzas: > > if [ "$OP" = "add" ]; then > iptables -N "${CN}2loc" > iptables -I vpn2loc -s $ADDRESS -j "${CN}2loc" > iptables -N "loc2${CN}" > iptables -I loc2vpn -d $ADDRESS -j "loc2${CN}" > case "$CN" in > "brian-laptop") > iptables -I "${CN}2loc" -p udp --sport 4569 --dport 4569 -j ACCEPT > iptables -I "${CN}2loc" -p udp --sport 123 --dport 123 -j ACCEPT > ;; > "peer1") > iptables -I "loc2${CN}" -s 10.75.22.1 -j ACCEPT > ;; > esac > else > if [ -n "$CN" ]; then > iptables -D vpn2loc -s $ADDRESS -j "${CN}2loc" > iptables -F "${CN}2loc" > iptables -X "${CN}2loc" > iptables -D loc2vpn -s $ADDRESS -j "vpn2${CN}" > iptables -F "vpn2${CN}" > iptables -X "vpn2${CN}" > fi > fi > > Where CN is the openvpn name for a peer, normalized to work well in > iptables rule names. > > This appears to be working pretty well with some obvious caveats: > > * goes to hell in a handbasket if shorewall needs to be restarte > * rules are in the learn script > * probably more caveats > > Any thoughts on how to roll this more properly into shorewall so that > rules are specified with the traditional rules syntax and that it > survives restarts? > > Cheers, > b. > >Hi Brian, A way round this could be to identify the current state of the OpenVPN internal routing table at the point where Shorewall restarts. You may already have this in your config but if not, set up the following directive in your OpenVPN server .conf file: status /var/log/openvpn-status.log After restarting the server, OpenVPN will maintain the current client list and internal routing table in this file as clients connect and disconnect. The routing table (among other things) lists the client IP and common name of each connected client. You could then add some commands to /etc/shorewall/started (run after a complete Shorewall start or restart) that parses the routing table in the openvpn-status.log file and greps for the client IPs and common names. Once you have that info, you just need to include the "add" logic from your attached script to create the appropriate chains and rules for each connected client. regards, Aidan ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
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 client logs off.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? b. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
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 ruleset is O(z**2) where z is the number of zones. The ruleset is basically a z*z matrix. While these effects have been minimized in Shorewall Perl, they still exist. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
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 4.0.6 * iptables-restore v1.4.0: Set foo doesn''t exist. So empty ipsets don''t get created by shorewall (for ipsets that don''t yet exist) to allow iptables-restore to complete without a syntax error? b. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
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 supported by Shorewall-perl > 4.0.6 > * iptables-restore v1.4.0: Set foo doesn''t exist. > > So empty ipsets don''t get created by shorewall (for ipsets that don''t > yet exist) to allow iptables-restore to complete without a syntax error?Shorewall has nothing to do with set creation or maintenance. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
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 would be the proper one) script to create the empty sets, but I wonder why Shorewall wouldn''t want to do that as it comes across ipset usage in the configuration. b. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
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 "init" (I think that would be > the proper one) script to create the empty sets, but I wonder why > Shorewall wouldn''t want to do that as it comes across ipset usage in the > configuration.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. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
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 (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 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. Cheers and thanks for the pointers, b. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
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 that the Netfilter team would get off of their collective asses and get ipsets into the mainstream. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
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 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0
state INVALID,NEW
2005 167K br-lan_mac all -- * * 0.0.0.0/0 0.0.0.0/0
state NEW
0 0 loc2all all -- * tun2 0.0.0.0/0 0.0.0.0/0
616 78730 loc2all all -- * tun0 0.0.0.0/0 0.0.0.0/0
118 15304 loc2all all -- * tun1 0.0.0.0/0 0.0.0.0/0
3146 352K loc2net all -- * ppp0 0.0.0.0/0 0.0.0.0/0
3517 371K loc2net all -- * eth0.1 0.0.0.0/0 0.0.0.0/0
0 0 loc2loc all -- * br-lan 0.0.0.0/0 0.0.0.0/0
0 0 loc2vpn1 all -- * tun0 0.0.0.0/0 0.0.0.0/0
set foo dst
So of course, a packet from br-lan to a network on interface tun0
matches the loc2all before it has a chance to be evaluated by the
loc2vpn1 rule.
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?
b.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer''s
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
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. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
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://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
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 is the compile script (for Shorewall-perl) that will discover any ipsets used in the hosts file and create empty ipsets for them if they don''t already exist. ---- cut ---- use File::Temp qw/ tempfile tempdir /; print "Finding used ipsets\n"; my @ipsets; open(HOSTS, "hosts") || die "failed to open hosts file: $!"; while (<HOSTS>) { s/#.*//; /^$/ && next; my ($zone, $hosts, $options ) = split('' ''); if ($hosts =~ /^.+:\+([a-zA-Z]\w*)$/) { push(@ipsets, $1); } } close(HOSTS); print "Creating init rules to create undefined ipsets\n"; my $fh; my $filename; if (open(INIT, "init")) { ($fh, $filename) = tempfile("initXXXXXX"); while (<INIT>) { # skip any old ipset creation commands if (/#START IPSET CREATION -- DO NOT REMOVE$/) { while (<INIT>) { /#END IPSET CREATION -- DO NOT REMOVE$/ && last; } $_ = <INIT>; } if (/^#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE$/) { print $fh "#START IPSET CREATION -- DO NOT REMOVE\n"; print $fh "/bin/echo -e \"Creating any undefined ipsets...\\c\"\n"; foreach my $ipset (@ipsets) { print $fh "ipset -L $ipset >/dev/null 2>&1 || { /bin/echo -e \"$ipset...\\c\"; ipset -N $ipset iphash; }\n" } print $fh "echo\n"; print $fh "#END IPSET CREATION -- DO NOT REMOVE\n"; } print $fh $_; } close($fh); } else { die "failed to open init script: $!" } close(INIT); # now replace init with the newly created file unlink("init"); link($filename, "init"); unlink($filename); ---- cut ---- Prints out a few nice messages as it works. Cheers, b. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
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") || die "failed to open hosts file: $!"; while (<HOSTS>) { s/#.*//; /^$/ && next; my ($zone, $hosts, $options ) = split('' ''); if ($hosts =~ /^.+:\+([a-zA-Z]\w*)$/) { push(@ipsets, $1); } } close(HOSTS); print "Creating init rules to create undefined ipsets\n"; open(INIT, "init") || die "failed to open init script: $!"; my ($fh, $filename) = tempfile("initXXXXXX"); while (<INIT>) { # skip any old ipset creation commands if (/#START IPSET CREATION -- DO NOT REMOVE$/) { while (<INIT>) { /#END IPSET CREATION -- DO NOT REMOVE$/ && last; } $_ = <INIT>; } if (/^#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE$/) { print $fh "#START IPSET CREATION -- DO NOT REMOVE\n"; print $fh "new_ipset() { local NAME=\"\$1\" ipset -L \"\$NAME\" >/dev/null 2>&1 || { /bin/echo -e \"\$NAME...\\c\" ipset -N \"\$NAME\" iphash } }\n\n"; print $fh "/bin/echo -e \"Creating any undefined ipsets...\\c\"\n"; foreach my $ipset (@ipsets) { #print $fh "ipset -L $ipset >/dev/null 2>&1 || { /bin/echo -e \"$ipset...\\c\"; ipset -N $ipset iphash; }\n" print $fh "new_ipset \"$ipset\"\n"; } print $fh "echo\n"; print $fh "#END IPSET CREATION -- DO NOT REMOVE\n"; } print $fh $_; } close($fh); close(INIT); # now replace init with the newly created file unlink("init"); link($filename, "init"); unlink($filename); ---- cut ---- Cheers again, b. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
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 Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
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. could I have avoided actually parsing the hosts file and found the ipsets enumerated into a data structure already? I suppose Data::Dumper could illustrate quite easily. b. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
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 perl vars? i.e. > could I have avoided actually parsing the hosts file and found the > ipsets enumerated into a data structure already?No. The ''compile'' user exit is called just before the zones file is processed. The ''initdone'' exit is called after zones, interfaces, hosts and policy have been processed. For zone-related information, see the comments at the top of Zones.pm. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
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 data enumerated into perl vars? i.e. >> could I have avoided actually parsing the hosts file and found the >> ipsets enumerated into a data structure already? > > No. The ''compile'' user exit is called just before the zones file is > processed. The ''initdone'' exit is called after zones, interfaces, hosts > and policy have been processed. For zone-related information, see the > comments at the top of Zones.pm.# hosts { <type> } => [ { <interface1> => { ipsec => ''ipsec''|''none'' # options => { <option1> => <value1> # ... # } # hosts => [ <net1> , <net2> , ... ] # } When a network in the inner hosts list starts with "+", it is an ipset. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/