I''m releasing 4.0.5 a bit early so that the 4.0.5 .deb packages can be uploaded into the Debian experimental repository. The sooner that is done, the sooner Debian and Ubuntu users will have access to Shorewall 4. Problems corrected in Shorewall 4.0.5. 1) Previously, Shorewall-perl mis-processed $FW::<port> in the DEST column of a REDIRECT rule, generating an error. ''$FW::<port>'' now produces the same effect as ''<port>''. 2) If the PROTOCOL (PROTO) column contained ''TCP'' or ''UDP'' and SOURCE PORT(S) or DEST PORT(S) were given, then Shorewall-perl rejected the entry with the error: ERROR: SOURCE/DEST PORT(S) not allowed with PROTO TCP : /etc/shorewall/rules The rule was accepted if ''tcp'' or ''udp'' was used instead. 3) Shorewall-shell now removes any default bindings of ipsets before attempting to reload them. Previously, default bindings were not removed with the result that the ipsets could not be destroyed. Other changes in Shorewall 4.0.5. 1) Two new options have been added to /etc/shorewall/hosts (Shorewall-perl only). broadcast: Permits limited broadcast (destination 255.255.255.255) to the zone. destonly: Normally used with the Multi-cast range. Specifies that traffic will be sent to the specified net(s) but that no traffic will be received from the net(s). Example: wifi eth1:192.168.3.0/24 broadcast wifi eth1:224.0.0.0/4 destonly In that example, limited broadcasts from the firewall with a source IP in the 192.168.3.0/24 range will be acccepted as will multicasts (with any source address). 2) A MULTICAST option has been added to shorewall.conf. This option will normally be set to ''No'' (the default). It should be set to ''Yes'' under the following circumstances: a) You have an interface that has parallel zones defined via /etc/shorewall/hosts. b) You want to forward multicast packets to two or more of those parallel zones. In such cases, you will configure a ''destonly'' network on each zone receiving multicasts. The MULTICAST option is only recognized by Shorewall-perl and is ignored by Shorewall-shell. 3) As announced in the Shorewall 4.0.4 release notes, Shorewall-perl no longer supports the ''detectnets'' option. Specifying that option now results in the following message: WARNING: Support for the ''detectnets'' option has been removed It is suggested that ''detectnets'' be replaced by ''routefilter,logmartians''. That will produce the same filtering effect as ''detectnets'' while eliminating 1-2 rules per connection. One user has asked how to retain the output of ''shorewall show zones'' if the ''detectnets'' option is removed. While I don''t advise doing so, you can reproduce the current ''shorewall show'' behavior as follows. Suppose that you have a zone named ''wifi'' that produces the following output with ''detectnets'': wifi (ipv4) eth1:192.168.3.0/24 You can reproduce this behavior as follows: /etc/shorewall/interfaces: - eth1 detect ... /etc/shorewall/hosts: wifi eth1:192.168.3.0/24 broadcast If you send multicast to the ''wifi'' zone, you also need this entry in your hosts file: wifi eth1:224.0.0.0/4 destonly 4) (Shorewall-perl only) The server port in a DNAT or REDIRECT rule may now be specified as a service name from /etc/services. Additionally: a) A port-range may be specified as the service port expressed in the format <low port>-<high port>. Connections are assigned to server ports in round-robin fashion. b) The compiler only permits a server port to be specified if the protocol is tcp or udp. c) The compiler ensures that the server IP address is valid (note that it is still not permitted to specify the server address as a DNS name). 5) (Shorewall-perl only) Users are complaining that when they migrate to Shorewall-perl, they have to restrict their port lists to 15 ports. In this release, we relax that restriction on destination port lists. Since the SOURCE PORT(s) column in the configuration files is rarely used, we have no plans to relax the restriction in that column. 6) There have been several cases where iptables-restore has failed while executing a COMMIT command in the .iptables_restore_input file. This gives neither the user nor Shorewall support much to go on when analyzing the problem. As a new debugging aid, the meaning of ''trace'' and ''debug'' have been changed. Traditionally, /sbin/shorewall and /sbin/shorewall-lite have allowed either ''trace'' or ''debug'' as the first run-line parameter. Prior to 4.0.5, the two words produced the same effect. Beginning with Shorewall 4.0.5, the two words have different effects when Shorewall-perl is used. trace - Like the previous behavior. In the Shorewall-perl compiler, generate a stack trace on WARNING and ERROR messages. In the generated script, sets the shell''s -x option to trace execution of the script. debug - Ignored by the Shorewall-perl compiler. In the generated script, causes the commands in .iptables_restore_input to be executed as discrete iptables commands. The failing command can thus be identified and a diagnosis of the cause can be made. Users of Shorewall-lite will see the following change when using a script that was compiled with Shorewall-perl 4.0.5 or later. trace - In the generated script, sets the shell''s -x option to trace execution of the script. debug - In the generated script, causes the commands in .iptables_restore_input to be executed as discrete iptables commands. The failing command can thus be identified and a diagnosis of the cause can be made. In all other cases, ''debug'' and ''trace'' remain synonymous. In particular, users of Shorewall-shell will see no change in behavior. WARNING: The ''debug'' feature in Shorewall-perl is strictly for problem analysis. When ''debug'' is used: a) The firewall is made ''wide open'' before the rules are applied. b) The routestopped file is not consulted and the rules are applied in the canonical iptables-restore order (ASCIIbetical by chain). So if you need critical hosts to be always available during start/restart, you may not be able to use ''debug''. 7) /usr/share/shorewall-perl/buildports.pl, /usr/share/shorewall-perl/FallbackPorts.pm and /usr/share/shorewall-perl/Shorewall/Ports.pm have been removed. Shorewall now resolves protocol and port names as using Perl''s interface to the the standard C library APIs getprotobyname() and getservbyname(). Note 1: The protocol names ''tcp'', ''TCP'', ''udp'', ''UDP'', ''all'', ''ALL'', ''icmp'' and ''ICMP'' are still resolved by Shorewall-perl itself. Note 2: Those of you running Shorewall-perl under Cygwin may wish to install "real" /etc/protocols and /etc/services files in place of the symbolic links installed by Cygwin. 8) The contents of the Shorewall::*::$VERSION variables are now a V-string (e.g., 4.0.5) rather than an integer (e.g., 4.05). This is only of interest for Perl programs that are using the modules and specifying a minimum version (e.g., "use Shorewall::Config 4.0.5;"). Each module continues to carry a separate version which indicates the release of Shorewall-perl when the module was last modified. -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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
hi, it seems there is some bug in this version. i''ve got this error: ERROR: Invalid port range (ms:wbt:server) : rules (line 49) for this line in rules: DNAT net loc:$WINDOWS_IP tcp https,pptp,ms-wbt-server,4125 Tom Eastep wrote:> I''m releasing 4.0.5 a bit early so that the 4.0.5 .deb packages can be > uploaded into the Debian experimental repository. The sooner that is > done, the sooner Debian and Ubuntu users will have access to Shorewall 4. > > Problems corrected in Shorewall 4.0.5. > > 1) Previously, Shorewall-perl mis-processed $FW::<port> in the DEST > column of a REDIRECT rule, generating an error. ''$FW::<port>'' now > produces the same effect as ''<port>''. > > 2) If the PROTOCOL (PROTO) column contained ''TCP'' or ''UDP'' and SOURCE > PORT(S) or DEST PORT(S) were given, then Shorewall-perl rejected > the entry with the error: > > ERROR: SOURCE/DEST PORT(S) not allowed with PROTO TCP : > /etc/shorewall/rules > > The rule was accepted if ''tcp'' or ''udp'' was used instead. > > 3) Shorewall-shell now removes any default bindings of ipsets before > attempting to reload them. Previously, default bindings were not > removed with the result that the ipsets could not be destroyed. > > Other changes in Shorewall 4.0.5. > > 1) Two new options have been added to /etc/shorewall/hosts > (Shorewall-perl only). > > broadcast: Permits limited broadcast (destination 255.255.255.255) > to the zone. > > destonly: Normally used with the Multi-cast range. Specifies that > traffic will be sent to the specified net(s) but that > no traffic will be received from the net(s). > > Example: > > wifi eth1:192.168.3.0/24 broadcast > wifi eth1:224.0.0.0/4 destonly > > In that example, limited broadcasts from the firewall with a source > IP in the 192.168.3.0/24 range will be acccepted as will multicasts > (with any source address). > > 2) A MULTICAST option has been added to shorewall.conf. This option > will normally be set to ''No'' (the default). It should be set to > ''Yes'' under the following circumstances: > > a) You have an interface that has parallel zones defined via > /etc/shorewall/hosts. > b) You want to forward multicast packets to two or more of those > parallel zones. > > In such cases, you will configure a ''destonly'' network on each > zone receiving multicasts. > > The MULTICAST option is only recognized by Shorewall-perl and is > ignored by Shorewall-shell. > > 3) As announced in the Shorewall 4.0.4 release notes, Shorewall-perl > no longer supports the ''detectnets'' option. Specifying that option > now results in the following message: > > WARNING: Support for the ''detectnets'' option has been removed > > It is suggested that ''detectnets'' be replaced by > ''routefilter,logmartians''. That will produce the same filtering > effect as ''detectnets'' while eliminating 1-2 rules per connection. > > One user has asked how to retain the output of ''shorewall show > zones'' if the ''detectnets'' option is removed. While I don''t advise > doing so, you can reproduce the current ''shorewall show'' behavior > as follows. > > Suppose that you have a zone named ''wifi'' that produces the > following output with ''detectnets'': > > wifi (ipv4) > eth1:192.168.3.0/24 > > You can reproduce this behavior as follows: > > /etc/shorewall/interfaces: > > - eth1 detect ... > > /etc/shorewall/hosts: > > wifi eth1:192.168.3.0/24 broadcast > > If you send multicast to the ''wifi'' zone, you also need this entry > in your hosts file: > > wifi eth1:224.0.0.0/4 destonly > > 4) (Shorewall-perl only) The server port in a DNAT or REDIRECT rule > may now be specified as a service name from > /etc/services. Additionally: > > a) A port-range may be specified as the service port expressed in > the format <low port>-<high port>. Connections are assigned to > server ports in round-robin fashion. > > b) The compiler only permits a server port to be specified if the > protocol is tcp or udp. > > c) The compiler ensures that the server IP address is valid (note > that it is still not permitted to specify the server address as a > DNS name). > > 5) (Shorewall-perl only) Users are complaining that when they migrate > to Shorewall-perl, they have to restrict their port lists to 15 > ports. In this release, we relax that restriction on destination > port lists. Since the SOURCE PORT(s) column in the configuration > files is rarely used, we have no plans to relax the restriction in > that column. > > 6) There have been several cases where iptables-restore has failed > while executing a COMMIT command in the .iptables_restore_input > file. This gives neither the user nor Shorewall support much to go > on when analyzing the problem. As a new debugging aid, the meaning > of ''trace'' and ''debug'' have been changed. > > Traditionally, /sbin/shorewall and /sbin/shorewall-lite have > allowed either ''trace'' or ''debug'' as the first run-line > parameter. Prior to 4.0.5, the two words produced the same effect. > > Beginning with Shorewall 4.0.5, the two words have different > effects when Shorewall-perl is used. > > trace - Like the previous behavior. > > In the Shorewall-perl compiler, generate a stack trace > on WARNING and ERROR messages. > > In the generated script, sets the shell''s -x option to > trace execution of the script. > > debug - Ignored by the Shorewall-perl compiler. > > In the generated script, causes the commands in > .iptables_restore_input to be executed as discrete iptables > commands. The failing command can thus be identified and a > diagnosis of the cause can be made. > > Users of Shorewall-lite will see the following change when using a > script that was compiled with Shorewall-perl 4.0.5 or later. > > trace - In the generated script, sets the shell''s -x option to > trace execution of the script. > > debug - In the generated script, causes the commands in > .iptables_restore_input to be executed as discrete iptables > commands. The failing command can thus be identified and a > diagnosis of the cause can be made. > > In all other cases, ''debug'' and ''trace'' remain synonymous. In > particular, users of Shorewall-shell will see no change in > behavior. > > WARNING: The ''debug'' feature in Shorewall-perl is strictly for > problem analysis. When ''debug'' is used: > > a) The firewall is made ''wide open'' before the rules are applied. > b) The routestopped file is not consulted and the rules are applied > in the canonical iptables-restore order (ASCIIbetical by chain). > So if you need critical hosts to be always available during > start/restart, you may not be able to use ''debug''. > > 7) /usr/share/shorewall-perl/buildports.pl, > /usr/share/shorewall-perl/FallbackPorts.pm and > /usr/share/shorewall-perl/Shorewall/Ports.pm have been removed. > > Shorewall now resolves protocol and port names as using Perl''s > interface to the the standard C library APIs getprotobyname() and > getservbyname(). > > Note 1: > > The protocol names ''tcp'', ''TCP'', ''udp'', ''UDP'', ''all'', ''ALL'', > ''icmp'' and ''ICMP'' are still resolved by Shorewall-perl > itself. > > Note 2: > > Those of you running Shorewall-perl under Cygwin may wish to > install "real" /etc/protocols and /etc/services files > in place of the symbolic links installed by Cygwin. > > 8) The contents of the Shorewall::*::$VERSION variables are now a > V-string (e.g., 4.0.5) rather than an integer (e.g., 4.05). This is > only of interest for Perl programs that are using the modules and > specifying a minimum version (e.g., "use Shorewall::Config > 4.0.5;"). Each module continues to carry a separate version which > indicates the release of Shorewall-perl when the module was last > modified. > > -Tom > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users-- Levente "Si vis pacem para bellum!" ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Farkas Levente wrote:> hi, > it seems there is some bug in this version. i''ve got this error: > ERROR: Invalid port range (ms:wbt:server) : rules (line 49) > for this line in rules: > DNAT net loc:$WINDOWS_IP tcp https,pptp,ms-wbt-server,4125To work around the problem, please replace ms-wbt-server by 3389 until I can devise a fix. -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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Tom Eastep wrote:> Farkas Levente wrote: >> hi, >> it seems there is some bug in this version. i''ve got this error: >> ERROR: Invalid port range (ms:wbt:server) : rules (line 49) >> for this line in rules: >> DNAT net loc:$WINDOWS_IP tcp https,pptp,ms-wbt-server,4125 > > To work around the problem, please replace ms-wbt-server by 3389 until I can > devise a fix.i already done, just wanna let you know:-) -- Levente "Si vis pacem para bellum!" ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Farkas Levente wrote:> Tom Eastep wrote: >> Farkas Levente wrote: >>> hi, >>> it seems there is some bug in this version. i''ve got this error: >>> ERROR: Invalid port range (ms:wbt:server) : rules (line 49) >>> for this line in rules: >>> DNAT net loc:$WINDOWS_IP tcp https,pptp,ms-wbt-server,4125 >> To work around the problem, please replace ms-wbt-server by 3389 until I can >> devise a fix. > > i already done, just wanna let you know:-) >I just posted the attached patch in the 4.0.5 Errata. -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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Tom Eastep wrote:> Farkas Levente wrote: >> Tom Eastep wrote: >>> Farkas Levente wrote: >>>> hi, >>>> it seems there is some bug in this version. i''ve got this error: >>>> ERROR: Invalid port range (ms:wbt:server) : rules (line 49) >>>> for this line in rules: >>>> DNAT net loc:$WINDOWS_IP tcp https,pptp,ms-wbt-server,4125 >>> To work around the problem, please replace ms-wbt-server by 3389 until I can >>> devise a fix. >> i already done, just wanna let you know:-) >> > > I just posted the attached patch in the 4.0.5 Errata.works. -- Levente "Si vis pacem para bellum!" ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Farkas Levente wrote:> Tom Eastep wrote: >> Farkas Levente wrote: >>> Tom Eastep wrote: >>>> Farkas Levente wrote: >>>>> hi, >>>>> it seems there is some bug in this version. i''ve got this error: >>>>> ERROR: Invalid port range (ms:wbt:server) : rules (line 49) >>>>> for this line in rules: >>>>> DNAT net loc:$WINDOWS_IP tcp https,pptp,ms-wbt-server,4125 >>>> To work around the problem, please replace ms-wbt-server by 3389 until I can >>>> devise a fix. >>> i already done, just wanna let you know:-) >>> >> I just posted the attached patch in the 4.0.5 Errata. > > works. >Here''s a slightly updated patch. The previous one broke the new feature allowing you to specify the server port using a service name. The errata patch has also been updated. -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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Finally have a shorewall 4.0.5 system running with multiple isps and ipsec vpns. Looking good so far :-) Have a few questions. I have the following in start: ip rule delete prio 200 table 200 ip route del table 200 ip route add 192.168.0.0/16 via 192.168.2.254 dev eth0 table 200 ip rule add prio 200 table 200 ..................................... 192.168.0.0/16 is the net of all the vpns 192.168.2.254 is the ip of the local network interface. This allows outgoing traffic to the vpn from the firewall. Is there a shorewall way to do this? Next are not really really shorewall issues but related. In debian etch they start openswan ipsec in rcS.d. This starts ipsec before bind. Rather annoying in this case as the box is the master dns for the domain and it seems silly to use ips. I have been concerned about maintaining qos through the vpns. From what I''m seeing the eps packets get the tos of the original packets. That saves a lot of problems. I''m thinking of doing vpn as gre through ipsec. Will this still happen? Thanks John ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
John McMonagle wrote:> Finally have a shorewall 4.0.5 system running with multiple isps and > ipsec vpns. > > Looking good so far :-) > > Have a few questions. > > I have the following in start: > ip rule delete prio 200 table 200 > ip route del table 200 > ip route add 192.168.0.0/16 via 192.168.2.254 dev eth0 table 200 > ip rule add prio 200 table 200 > ..................................... > 192.168.0.0/16 is the net of all the vpns > 192.168.2.254 is the ip of the local network interface. > > This allows outgoing traffic to the vpn from the firewall. > > Is there a shorewall way to do this?Yes -- but why don''t you simply put those in the eth0 stanza in /etc/network/interfaces as a series of post-up and pre-down commands? They have nothing to do with the firewall configuration. And I don''t see why it needs to be a separate routing table? Why not just add the route to the main table? Or better yet, why do you need it at all? I assume that your default route is out of eth0. -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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Tom Eastep wrote:>John McMonagle wrote: > > >>Finally have a shorewall 4.0.5 system running with multiple isps and >>ipsec vpns. >> >>Looking good so far :-) >> >>Have a few questions. >> >>I have the following in start: >>ip rule delete prio 200 table 200 >>ip route del table 200 >>ip route add 192.168.0.0/16 via 192.168.2.254 dev eth0 table 200 >>ip rule add prio 200 table 200 >>..................................... >>192.168.0.0/16 is the net of all the vpns >>192.168.2.254 is the ip of the local network interface. >> >>This allows outgoing traffic to the vpn from the firewall. >> >>Is there a shorewall way to do this? >> >> > >Yes -- but why don''t you simply put those in the eth0 stanza in >/etc/network/interfaces as a series of post-up and pre-down commands? They >have nothing to do with the firewall configuration. > >And I don''t see why it needs to be a separate routing table? Why not just >add the route to the main table? > >Or better yet, why do you need it at all? I assume that your default route >is out of eth0. > >-Tom > > >------------------------------------------------------------------------ >The default routes are eth1 and eth2. Without that rule if the destination is via vpn it will use an external ip. Then return packets will fail because they will not go via vpn. Yes probably a bit over kill with the rule. Just want to make sure it came before the default route. John ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/