The second Beta is now available at:
http://www.shorewall.net/pub/shorewall/Beta
ftp://ftp.shorewall.net/pub/shorewall/Beta
Function from 1.3 that has been omitted from this version includes:
1) The ''check'' command is no longer supported.
2) The MERGE_HOSTS variable in shorewall.conf is no longer
supported. Shorewall 1.4 behavior is the same as 1.3 with
MERGE_HOSTS=Yes.
3) Interface names of the form <device>:<integer> in
/etc/shorewall/interfaces now generate an error.
4) Shorewall 1.4 implements behavior consistent with
OLD_PING_HANDLING=No. OLD_PING_HANDLING=Yes will generate an error
at startup as will specification of the ''noping'' or
''filterping''
interface options.
5) The ''routestopped'' option in the /etc/shorewall/interfaces
and
/etc/shorewall/hosts files is no longer supported and will generate
an error at startup if specified.
6) The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer
accepted.
7) The ALLOWRELATED variable in shorewall.conf is no longer
supported. Shorewall 1.4 behavior is the same as 1.3 with
ALLOWRELATED=Yes.
8) The ''multi'' interface option is no longer supported.
Shorewall will
generate rules for sending packets back out the same interface
that they arrived on in two cases:
a) There is an _explicit_ policy for the source zone to the
destination zone. An explicit policy names both zones and does not
use the ''all'' reserved word.
b) There are one or more rules for traffic for the source zone to
or from the destination zone including rules that use the
''all''
reserved word. Exception: If the source and the destination are
the same zone then the rule must be explicit - it must name the zone
in both the SOURCE and DESTINATION columns.
Changes for 1.4 include:
1) shorewall.conf has been completely reorganized into logical
sections.
2) LOG is now a valid action for a rule (/etc/shorewall/rules).
3) The firewall script and version file are now installed in
/usr/share/shorewall.
4. Late arriving DNS replies are now silently dropped in the common
chain by default.
5) In addition to behaving like OLD_PING_HANDLING=No, Shorewall 1.4 no
longer unconditionally accepts outbound ICMP packets. So if you want
to ''ping'' from the firewall, you will need the appropriate
rule or
policy.
6) CONTINUE is now a valid action for a rule (/etc/shorewall/rules).
7) 802.11b devices with names of the form wlan<n> now support the
''maclist'' option.
8) IMPORTANT: Shorewall now REQUIRES the iproute package (''ip''
utility).
9) Explicit Congestion Notification (ECN - RFC 3168) may now be turned
off on a host or network basis using the new /etc/shorewall/ecn
file. To use this facility:
a) You must be running kernel 2.4.20
b) You must have applied the patch in
http://www.shorewall/net/pub/shorewall/ecn/patch.
c) You must have iptables 1.2.7a installed.
-Tom
--
Tom Eastep \ Shorewall - iptables made easy
Shoreline, \ http://www.shorewall.net
Washington USA \ teastep@shorewall.net
Hi all, after setting an ipsec tunnel between two sites under my administration, I?ve stuck into a problem. Some of the workstations on the remote site are protected with a personal firewall (Norton Internet Security) and I want to be able to VNC into them to solve some minor problems remotely (printer usage, application configuration and so on). The problem is that NIS wants to create a rule for every IP that tries to connect to VNC (we are a team of 5 here). So I thought I could use SNAT to change our address when we enter the remote network. In the remote firewall, I used the masq table and added an entry: eth1 ipsec0 192.168.55.100 eth1 is the internal interface of the remote side of the tunnel ipsec0 is the virtual interface for the tunnel the problem is that, when shorewall starts and try to create that rule into the nat tables, It issues the error: [...snip...] Masqueraded Subnets and Hosts: To 0.0.0.0/0 from 192.168.55.0/24 through eth0 using WWW.XXX.YYY.ZZZ Interface ipsec0 must be up before Shorewall starts [...snip...] I followed the instructions for setting a ipsec tunnel from the documentation and I know that the init file stops the ipsec service in the beggining of the process of starting shorewall (or restarting, or trying). So, the ipsec0 interface is down when the masq table is processed. Any ideas? Am I doing something impossible? I?m using shorewall 1.3.13 with iptables 1.2.7a and Freeswan 1.99 on both sides. TIA, ________________________ Eduardo Ferreira Sup. Suporte e Rede (5521) 3804-8606 ps: sorry for the long post.
--On Thursday, February 27, 2003 02:05:39 PM -0300 Eduardo Ferreira <duda@icatu.com.br> wrote:> Hi all, > > after setting an ipsec tunnel between two sites under my administration, > I?ve stuck into a problem. Some of the workstations on the remote site > are protected with a personal firewall (Norton Internet Security) and I > want to be able to VNC into them to solve some minor problems remotely > (printer usage, application configuration and so on). The problem is > that NIS wants to create a rule for every IP that tries to connect to > VNC (we are a team of 5 here). So I thought I could use SNAT to change > our address when we enter the remote network. In the remote firewall, I > used the masq table and added an entry: > > eth1 ipsec0 192.168.55.100 > > eth1 is the internal interface of the remote side of the tunnel > ipsec0 is the virtual interface for the tunnelThe documentation clearly states that if you use an interface name in the second column of a masq table entry then the interface must be up when you start Shorewall. You need to specify the local subnetwork at your end of the tunnel in that column. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
I was trying to avoid that... I don?t like giving IP address around, if I can... thanks, Tom. shorewall-users-bounces@lists.shorewall.net wrote on 27/02/2003 14:34:55:> > > --On Thursday, February 27, 2003 02:05:39 PM -0300 Eduardo Ferreira > <duda@icatu.com.br> wrote: > > > Hi all, > > > > after setting an ipsec tunnel between two sites under myadministration,> > I?ve stuck into a problem. Some of the workstations on the remotesite> > are protected with a personal firewall (Norton Internet Security) andI> > want to be able to VNC into them to solve some minor problems remotely > > (printer usage, application configuration and so on). The problem is > > that NIS wants to create a rule for every IP that tries to connect to > > VNC (we are a team of 5 here). So I thought I could use SNAT tochange> > our address when we enter the remote network. In the remotefirewall, I> > used the masq table and added an entry: > > > > eth1 ipsec0 192.168.55.100 > > > > eth1 is the internal interface of the remote side of the tunnel > > ipsec0 is the virtual interface for the tunnel > > The documentation clearly states that if you use an interface name inthe> second column of a masq table entry then the interface must be up whenyou> start Shorewall. You need to specify the local subnetwork at your end of> the tunnel in that column. > > -Tom > -- > Tom Eastep \ Shorewall - iptables made easy > Shoreline, \ http://www.shorewall.net > Washington USA \ teastep@shorewall.net > > _______________________________________________ > Shorewall-users mailing list > Post: Shorewall-users@lists.shorewall.net > Subscribe/Unsubscribe: http://lists.shorewall. > net/mailman/listinfo/shorewall-users > Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htm
--On Thursday, February 27, 2003 03:24:15 PM -0300 Eduardo Ferreira <duda@icatu.com.br> wrote:> > I was trying to avoid that... I don?t like giving IP address around, if > I can... >The problem is that SNAT/MASQ occurs in the POSTROUTING chain where iptables disallows the "-i" option. That means that for a masquerade or SNAT rule, the source must be specified by address; it cannot be specified by interface. The reason that Shorewall therefore requires a source interface to be up when Shorewall is starting is so that Shorewall can query the routing table to determine what addresses are routed out the specified interface. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
Oh man, how much I still have to learn... thank you Tom. Eduardo shorewall-users-bounces@lists.shorewall.net wrote on 27/02/2003 16:21:02:> > > --On Thursday, February 27, 2003 03:24:15 PM -0300 Eduardo Ferreira > <duda@icatu.com.br> wrote: > > > > > I was trying to avoid that... I don?t like giving IP address around,if> > I can... > > > > The problem is that SNAT/MASQ occurs in the POSTROUTING chain where > iptables disallows the "-i" option. That means that for a masquerade or > SNAT rule, the source must be specified by address; it cannot bespecified> by interface. > > The reason that Shorewall therefore requires a source interface to be up> when Shorewall is starting is so that Shorewall can query the routingtable> to determine what addresses are routed out the specified interface. > > -Tom > -- > Tom Eastep \ Shorewall - iptables made easy > Shoreline, \ http://www.shorewall.net > Washington USA \ teastep@shorewall.net > > _______________________________________________ > Shorewall-users mailing list > Post: Shorewall-users@lists.shorewall.net > Subscribe/Unsubscribe: http://lists.shorewall. > net/mailman/listinfo/shorewall-users > Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htm
Eduardo Ferreira wrote:> > Oh man, how much I still have to learn... >I try to learn those details so you folks don''t have to :-) -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net