2004-12-26 00:19:43 +01:00
|
|
|
Shorewall 2.2.0-RC3
|
2004-01-31 17:11:22 +01:00
|
|
|
|
2004-02-10 01:04:10 +01:00
|
|
|
----------------------------------------------------------------------
|
2004-06-28 19:53:31 +02:00
|
|
|
Problems Corrected since 2.0.3
|
|
|
|
|
|
|
|
1) A non-empty DEST entry in /etc/shorewall/tcrules will generate an
|
|
|
|
error and Shorewall fails to start.
|
|
|
|
|
|
|
|
2) A potential security vulnerablilty in the way that Shorewall
|
|
|
|
handles temporary files and directories has been corrected.
|
|
|
|
|
2004-07-06 22:41:53 +02:00
|
|
|
3) Two problems with logging NAT rules (DNAT and REDIRECT) could cause
|
|
|
|
startup failures.
|
|
|
|
|
2004-07-12 15:01:55 +02:00
|
|
|
4) Some users have reported the pkttype match option in iptables/
|
|
|
|
Netfilter failing to match certain broadcast packets. The result
|
|
|
|
is that the firewall log shows a lot of broadcast packets.
|
|
|
|
|
|
|
|
Users experiencing this problem can use PKTTYPE=No in
|
|
|
|
shorewall.conf to cause Shorewall to use IP address filtering of
|
|
|
|
broadcasts rather than packet type.
|
|
|
|
|
2004-07-10 19:03:31 +02:00
|
|
|
Problems Corrected since 2.1.0
|
|
|
|
|
|
|
|
1) The "check" command fails with the following message:
|
|
|
|
|
|
|
|
iptables: No chain/target/match by that name
|
|
|
|
|
2004-08-16 18:28:44 +02:00
|
|
|
Problems Corrected since 2.1.4
|
|
|
|
|
|
|
|
1) Per-interface options like 'norfc1918' are not applied to requests
|
|
|
|
that have been unencrypted as a result of an entry in the SPD.
|
|
|
|
|
2004-08-28 00:16:22 +02:00
|
|
|
Problems corrected since 2.1.6
|
|
|
|
|
|
|
|
1) Dynamic zones marked as 'ipsec' in /etc/shorewall/ipsec now work
|
|
|
|
correctly.
|
|
|
|
|
2004-08-29 19:21:16 +02:00
|
|
|
Problems corrected since 2.1.7
|
|
|
|
|
|
|
|
1) Fix parsing of ACTION with ":" but no log level (Richard Musil).
|
|
|
|
|
2004-09-02 19:12:39 +02:00
|
|
|
2) Fix parsing of PROTO column in /etc/shorewall/tcrules.
|
|
|
|
|
2004-09-06 21:58:10 +02:00
|
|
|
3) Packets that will be encrypted or that have been decrypted by IPSEC
|
|
|
|
are now exempted from the rules established by one-to-one NAT. This
|
|
|
|
allows tunnel mode IPSEC to work for local networks where some of
|
|
|
|
the systems use one-to-one NAT.
|
|
|
|
|
2004-09-07 01:46:26 +02:00
|
|
|
4) The shorewall.spec file now directs rpm to cause Shorewall to start
|
|
|
|
automatically at boot. This feature was inadvertently removed in
|
|
|
|
Shorewall 2.1.3.
|
|
|
|
|
2004-09-09 22:18:49 +02:00
|
|
|
Problems corrected since 2.1.8
|
|
|
|
|
|
|
|
1) IP ranges in the routestopped and tunnels files now work.
|
|
|
|
|
|
|
|
2) Rules where an IP range appears in both the source and destination
|
|
|
|
now work correctly.
|
|
|
|
|
2004-09-10 23:41:10 +02:00
|
|
|
3) With complex proxy arp configurations involving two or more
|
|
|
|
ordered pairs of interfaces, the /proc/sys/net/ipv4/conf/*/proxy_arp
|
|
|
|
flags were sometimes set incorrectly. This has been fixed.
|
2004-09-23 16:30:54 +02:00
|
|
|
|
|
|
|
Problems corrected since 2.1.9
|
|
|
|
|
|
|
|
1) With DELAYBLACKLISTLOAD=No, the blacklist was previously not
|
|
|
|
loaded.
|
|
|
|
|
2004-10-08 02:17:55 +02:00
|
|
|
Problems corrected since 2.1.10
|
|
|
|
|
|
|
|
1) If TC_ENABLED=Yes but you have no /etc/shorewall/tcstart file then
|
|
|
|
"shorewall restore" will no longer attempt to run the tcstart file.
|
|
|
|
|
2004-10-09 02:06:45 +02:00
|
|
|
2) Previously it was necessary to define ipsec zones (those with
|
|
|
|
"Yes" in the IPSEC column in /etc/shorewall/ipsec or those having
|
|
|
|
an entry in /etc/shorewall/hosts having the "ipsec" option) before
|
|
|
|
other zones using the same interface. This has been corrected.
|
|
|
|
|
2004-10-11 23:16:48 +02:00
|
|
|
3) A typo has been corrected that prevented the 'logmartians' interface
|
|
|
|
option from working correctly.
|
|
|
|
|
2004-10-12 16:56:15 +02:00
|
|
|
4) A typo has been corrected in and a clarification added to the
|
|
|
|
/etc/shorewall/blacklist file.
|
|
|
|
|
2004-10-15 00:31:52 +02:00
|
|
|
Problems corrected since 2.1.11
|
|
|
|
|
|
|
|
1) If a zone name appears more than once in /etc/shorewall/zones,
|
|
|
|
Shorewall will now issue an error message and terminate during
|
|
|
|
"shorewall [re]start" or "shorewall check".
|
|
|
|
|
2004-10-20 17:28:47 +02:00
|
|
|
2) If a configuration has two or more "complex" zones (zones having
|
|
|
|
IPSEC hosts or zones having more than one subnet on an interface)
|
|
|
|
then an incorrect ruleset is generated. This problem was introduced
|
|
|
|
in 2.1.11.
|
|
|
|
|
2004-10-25 15:52:59 +02:00
|
|
|
Problems corrected since 2.2.0 Beta 1.
|
|
|
|
|
|
|
|
1) The "shorewall check" command results in the (harmless) error
|
|
|
|
message:
|
|
|
|
|
|
|
|
/usr/share/shorewall/firewall: line 2753:
|
|
|
|
check_dupliate_zones: command not found
|
2004-10-25 23:20:53 +02:00
|
|
|
|
|
|
|
2) The AllowNTP standard action now allows outgoing responses to
|
2004-10-26 16:48:21 +02:00
|
|
|
broadcasts.
|
|
|
|
|
|
|
|
3) A clarification has been added to the hosts file's description of
|
|
|
|
the 'ipsec' option pointing out that the option is redundent if the
|
|
|
|
zone named in the ZONE column has been designated an IPSEC zone in
|
2004-11-02 22:13:52 +01:00
|
|
|
the /etc/shorewall/ipsec file.
|
|
|
|
|
|
|
|
Problems corrected since 2.2.0 Beta 2.
|
|
|
|
|
2004-11-04 19:18:20 +01:00
|
|
|
1) Missing '#' in the rfc1918 file.
|
|
|
|
|
2004-11-09 22:55:11 +01:00
|
|
|
2) The INSTALL file now includes special instructions for Slackware
|
2004-11-04 19:18:20 +01:00
|
|
|
users.
|
2004-10-25 15:52:59 +02:00
|
|
|
|
2004-11-12 16:08:30 +01:00
|
|
|
Problems corrected since 2.2.0 Beta 3.
|
|
|
|
|
|
|
|
1) A cut and paste error resulted in some nonsense in the description
|
|
|
|
of the IPSEC column in /etc/shorewall/masq.
|
|
|
|
|
|
|
|
2) A typo in /etc/shorewall/rules has been corrected.
|
|
|
|
|
|
|
|
3) The bogons file has been updated.
|
2004-11-19 18:30:26 +01:00
|
|
|
|
|
|
|
4) The "shorewall add" command previously reported success but did
|
|
|
|
nothing -- now it works.
|
2004-11-25 21:24:21 +01:00
|
|
|
|
|
|
|
Problems corrected since 2.2.0 Beta 4:
|
|
|
|
|
|
|
|
1) A typo in shorewall.conf (NETNOTSYN) has been corrected.
|
2004-11-27 00:24:50 +01:00
|
|
|
|
|
|
|
Problems corrected since 2.2.0 Beta 5:
|
|
|
|
|
|
|
|
1) Many problems associated with an empty IPTABLES variable have been
|
|
|
|
corrected.
|
|
|
|
|
2004-11-27 00:33:32 +01:00
|
|
|
2) A 'chain already exists' error occurs on "shorewall add" if you are
|
|
|
|
using the 'mss' option in the ipsec file.
|
|
|
|
|
2004-11-27 17:12:14 +01:00
|
|
|
Problems corrected since 2.2.0 Beta 6:
|
|
|
|
|
|
|
|
1) The "shorewall add" and "shorewall delete" commands now work in a
|
|
|
|
bridged environment. The syntax is:
|
|
|
|
|
|
|
|
shorewall add <interface>[:<port>]:<address> <zone>
|
|
|
|
shorewall delete <interface>[:<port>]:<address> <zone>
|
|
|
|
|
|
|
|
Examples:
|
|
|
|
|
|
|
|
shorewall add br0:eth2:192.168.1.3 OK
|
|
|
|
shorewall delete br0:eth2:192.168.1.3 OK
|
|
|
|
|
2004-11-30 22:57:36 +01:00
|
|
|
2) Previously, "shorewall save" created an out-of-sequence restore
|
|
|
|
script. The commands saved in the user's /etc/shorewall/start script
|
|
|
|
were executed prior to the Netfilter configuration being
|
|
|
|
restored. This has been corrected so that "shorewall save" now
|
|
|
|
places those commands at the end of the script.
|
|
|
|
|
|
|
|
To accomplish this change, the "restore base" file
|
|
|
|
(/var/lib/shorewall/restore-base) has been split into two files:
|
|
|
|
|
|
|
|
/var/lib/shorewall/restore-base -- commands to be executed before
|
|
|
|
Netfilter the configuration is restored.
|
|
|
|
|
|
|
|
/var/lib/shorewall/restore-tail -- commands to be executed after the
|
|
|
|
Netfilter configuration is restored.
|
|
|
|
|
2004-12-01 22:12:01 +01:00
|
|
|
3) Previously, traffic from the firewall to a dynamic zone member host
|
|
|
|
did not need to match the interface specified when the host was
|
|
|
|
added to the zone. For example, if eth0:1.2.3.4 is added to dynamic
|
|
|
|
zone Z then traffic out of any firewall interface to 1.2.3.4 will
|
|
|
|
obey the fw->Z policies and rules. This has been corrected.
|
|
|
|
|
2004-12-04 00:18:28 +01:00
|
|
|
4) Shorewall uses the temporary chain 'fooX1234' to probe iptables for
|
|
|
|
detrmining which features are supported. Previously, if that chain
|
|
|
|
happened to exist when Shorewall was run, capabilities were
|
|
|
|
mis-detected.
|
|
|
|
|
2004-12-07 16:17:02 +01:00
|
|
|
Problems corrected since 2.2.0 Beta 7:
|
|
|
|
|
|
|
|
1) A typo in the /etc/shorewall/interfaces file has been corrected.
|
|
|
|
|
2004-12-08 21:00:03 +01:00
|
|
|
2) The "add" and "delete" commands were generating incorrect policy
|
|
|
|
matches when policy match support was available.
|
|
|
|
|
2004-12-13 19:51:00 +01:00
|
|
|
Problems corrected since 2.2.0 Beta 8:
|
|
|
|
|
|
|
|
1) The syntax of the add and delete command has been clarified in the
|
|
|
|
help summary produced by /sbin/shorewall.
|
|
|
|
|
2004-12-26 00:19:43 +01:00
|
|
|
Problems corrected since 2.2.0 RC2
|
|
|
|
|
|
|
|
1) The following error message could appear during "shorewall stop" or
|
|
|
|
"shorewall clear":
|
|
|
|
|
|
|
|
local: lo:: bad variable name
|
|
|
|
|
2004-12-28 19:15:49 +01:00
|
|
|
2) The rate limiting example in /etc/shorewall/rules has been changed
|
2004-12-29 01:06:02 +01:00
|
|
|
to use the RATE LIMIT column.
|
|
|
|
|
|
|
|
3) Entries in /etc/shorewall/masq with the INTERFACE column containing
|
|
|
|
<ifname>:: would generate a progress message but would not generate
|
|
|
|
an iptables rule.
|
2004-12-30 17:08:41 +01:00
|
|
|
|
|
|
|
4) A misleading typo in /etc/shorewall/tunnels has been corrected.
|
2004-01-31 20:06:39 +01:00
|
|
|
-----------------------------------------------------------------------
|
2004-12-14 20:55:51 +01:00
|
|
|
Issues when migrating from Shorewall 2.0 to Shorewall 2.2:
|
2004-05-01 04:20:58 +02:00
|
|
|
|
2004-07-25 00:17:13 +02:00
|
|
|
1) Shorewall configuration files except shorewall.conf are now empty
|
|
|
|
(they contain only comments). If you wish to retain the defaults
|
|
|
|
in any of the following files, you should copy these files before
|
|
|
|
upgrading them then restore them after the upgrade:
|
|
|
|
|
|
|
|
/etc/shorewall/zones
|
|
|
|
/etc/shorewall/policy
|
|
|
|
/etc/shorewall/tos
|
2004-05-27 20:18:41 +02:00
|
|
|
|
2004-07-28 21:22:00 +02:00
|
|
|
2) The following builtin actions have been removed and have been
|
|
|
|
replaced by the new action logging implementation described in the
|
|
|
|
new features below.
|
|
|
|
|
|
|
|
logNotSyn
|
|
|
|
rLogNotSyn
|
|
|
|
dLogNotSyn
|
|
|
|
|
2004-08-07 17:27:52 +02:00
|
|
|
3) If shorewall.conf is upgraded to the latest version, it needs to be
|
|
|
|
modified to set STARTUP_ENABLED=Yes
|
|
|
|
|
2004-08-09 16:52:35 +02:00
|
|
|
4) The Leaf/Bering version of Shorewall was previously named:
|
|
|
|
|
|
|
|
shorwall-<version>.lrp
|
|
|
|
|
|
|
|
Beginning with 2.1, that file will now be named:
|
|
|
|
|
|
|
|
shorewall-lrp-<version>.tgz
|
|
|
|
|
|
|
|
Simply rename that file to 'shorwall.lrp' when installing it on your
|
|
|
|
LEAF/Bering system.
|
|
|
|
|
2004-08-11 02:17:54 +02:00
|
|
|
5) The ORIGINAL DEST column of the /etc/shorewall/rules file may no
|
|
|
|
longer contain a second (SNAT) address. You must use an entry in
|
|
|
|
/etc/shorewall/masq instead.
|
|
|
|
|
|
|
|
Example from Shorewall FAQ #1:
|
|
|
|
|
|
|
|
Prior to Shorewall 2.1:
|
|
|
|
|
|
|
|
/etc/shorewall/interfaces
|
|
|
|
|
|
|
|
loc eth1 detect routeback,...
|
|
|
|
|
|
|
|
/etc/shorewall/rules
|
|
|
|
|
|
|
|
DNAT loc loc:192.168.1.12 tcp 80 \
|
|
|
|
- 130.252.100.69:192.168.1.254
|
|
|
|
|
|
|
|
Shorewall 2.1 and Later:
|
|
|
|
|
|
|
|
/etc/shorewall/interfaces
|
|
|
|
|
|
|
|
loc eth1 detect routeback,...
|
|
|
|
|
|
|
|
/etc/shorewall/masq:
|
|
|
|
|
|
|
|
eth1 eth1 192.168.1.254 tcp 80
|
|
|
|
|
|
|
|
|
|
|
|
/etc/shorewall/rules:
|
|
|
|
|
|
|
|
DNAT loc loc:192.168.1.12 tcp 80 \
|
|
|
|
- 130.252.100.69
|
|
|
|
|
2004-09-09 22:42:50 +02:00
|
|
|
6) The 'logunclean' and 'dropunclean' options that were deprecated in
|
|
|
|
Shorewall 2.0 have now been removed completely.
|
|
|
|
|
2004-11-26 19:44:42 +01:00
|
|
|
7) A new IPTABLES variable has been added to shorewall.conf. This
|
|
|
|
variable names the iptables executable that Shorewall will use. The
|
|
|
|
variable is set to "/sbin/iptables". If you use the new
|
|
|
|
shorewall.conf, you may need to change this setting to maintain
|
|
|
|
compabibility with your current setup (if you use your existing
|
|
|
|
shorewall.conf that does not set IPTABLES then you should
|
|
|
|
experience no change in behavior).
|
|
|
|
|
2004-12-19 21:38:52 +01:00
|
|
|
8) The default port for OpenVPN tunnels has been changed from 5000 to
|
|
|
|
1194 to reflect the recent IANA allocation of that port for
|
|
|
|
OpenVPN.
|
|
|
|
|
2004-05-27 18:27:50 +02:00
|
|
|
-----------------------------------------------------------------------
|
2004-01-31 17:11:22 +01:00
|
|
|
New Features:
|
|
|
|
|
2004-07-01 16:12:29 +02:00
|
|
|
1) ICMP packets that are in the INVALID state are now dropped by the
|
|
|
|
Reject and Drop default actions. They do so using the new
|
|
|
|
'dropInvalid' builtin action.
|
2004-07-13 02:33:30 +02:00
|
|
|
|
|
|
|
2) The /etc/shorewall/masq file INTERFACE column now allows additional
|
|
|
|
options.
|
|
|
|
|
|
|
|
Normally MASQUERADE/SNAT rules are evaluated after one-to-one NAT
|
|
|
|
rules defined in the /etc/shorewall/nat file. If you preceed the
|
|
|
|
interface name with a plus sign ("+") then the rule will be
|
|
|
|
evaluated before one-to-one NAT.
|
|
|
|
|
|
|
|
Examples:
|
|
|
|
|
|
|
|
+eth0
|
|
|
|
+eth1:192.0.2.32/27
|
|
|
|
|
|
|
|
Also, the effect of ADD_SNAT_ALIASES=Yes can be negated for an
|
|
|
|
entry by following the interface name by ":" but no digit.
|
|
|
|
|
|
|
|
Examples:
|
|
|
|
|
|
|
|
eth0:
|
|
|
|
eth1::192.0.2.32/27
|
|
|
|
+eth3:
|
|
|
|
|
2004-07-15 22:29:06 +02:00
|
|
|
3) Similar to 2), the /etc/shorewall/nat file INTERFACE column now allows
|
|
|
|
you to override the setting of ADD_IP_ALIASES=Yes by following the
|
|
|
|
interface name with ":" but no digit.
|
|
|
|
|
2004-07-25 03:30:09 +02:00
|
|
|
4) All configuration files in the Shorewall distribution with the
|
|
|
|
exception of shorewall.conf are now empty. In particular, the
|
|
|
|
/etc/shorewall/zones, /etc/shorewall/policy and /etc/shorewall/tos
|
|
|
|
files now have no active entries. Hopefully this will stop the
|
|
|
|
questions on the support and development lists regarding why the
|
|
|
|
default entries are the way they are.
|
2004-07-13 02:33:30 +02:00
|
|
|
|
2004-10-12 18:38:46 +02:00
|
|
|
5) Previously, including a log level (and optionally a log tag) on a
|
2004-07-28 04:36:40 +02:00
|
|
|
rule that specified a user-defined (or Shorewall-defined) action
|
|
|
|
would log all traffic passed to the action. Beginning with this
|
|
|
|
release, specifying a log level in a rule that specifies a user-
|
|
|
|
or Shorewall-defined action will cause each rule in the action to
|
|
|
|
be logged with the specified level (and tag).
|
|
|
|
|
|
|
|
The extent to which logging of action rules occurs is goverend by
|
|
|
|
the following:
|
|
|
|
|
|
|
|
a) When you invoke an action and specify a log level, only those
|
|
|
|
rules in the action that have no log level will be changed to log
|
|
|
|
at the level specified at the action invocation.
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
/etc/shorewall/action.foo:
|
|
|
|
|
|
|
|
ACCEPT - - tcp 22
|
|
|
|
bar:info
|
|
|
|
|
|
|
|
/etc/shorewall/rules:
|
|
|
|
|
|
|
|
foo:debug fw net
|
|
|
|
|
2004-10-12 18:38:46 +02:00
|
|
|
Logging in the invoked 'foo' action will be:
|
2004-07-28 04:36:40 +02:00
|
|
|
|
|
|
|
ACCEPT:debug - - tcp 22
|
|
|
|
bar:info
|
|
|
|
|
|
|
|
b) If you follow the log level with "!" then logging will
|
|
|
|
be at that level for all rules recursively invoked by the action
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
/etc/shorewall/action.foo:
|
|
|
|
|
|
|
|
ACCEPT - - tcp 22
|
|
|
|
bar:info
|
|
|
|
|
|
|
|
/etc/shorewall/rules:
|
|
|
|
|
|
|
|
foo:debug! fw net
|
|
|
|
|
|
|
|
Logging in the invoke 'foo' action will be:
|
|
|
|
|
|
|
|
ACCEPT:debug - - tcp 22
|
|
|
|
bar:debug!
|
|
|
|
|
2004-07-28 21:22:00 +02:00
|
|
|
This change has an effect on extension scripts used with
|
|
|
|
user-defined actions. If you define an action 'acton' and you have
|
2004-10-12 18:38:46 +02:00
|
|
|
an /etc/shorewall/acton script then when that script is invoked,
|
2004-07-28 21:22:00 +02:00
|
|
|
the following three variables will be set for use by the script:
|
|
|
|
|
|
|
|
$CHAIN = the name of the chain where your rules are to be
|
|
|
|
placed. When logging is used on an action invocation,
|
|
|
|
Shorewall creates a chain with a slightly different name from
|
|
|
|
the action itself.
|
|
|
|
|
|
|
|
$LEVEL = Log level. If empty, no logging was specified.
|
|
|
|
|
|
|
|
$TAG = Log Tag.
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
/etc/shorewall/rules:
|
|
|
|
|
|
|
|
acton:info:test
|
|
|
|
|
|
|
|
Your /etc/shorewall/acton file will be run with:
|
|
|
|
|
2004-10-12 18:38:46 +02:00
|
|
|
$CHAIN="%acton1"
|
2004-07-28 21:22:00 +02:00
|
|
|
$LEVEL="info"
|
|
|
|
$TAG="test"
|
2004-07-28 04:36:40 +02:00
|
|
|
|
2004-08-02 23:48:40 +02:00
|
|
|
6) The /etc/shorewall/startup_disabled file is no longer created when
|
|
|
|
Shorewall is first installed. Rather, the variable STARTUP_ENABLED
|
|
|
|
is set to 'No' in /etc/shorewall/shorewall.conf. In order to get
|
|
|
|
Shorewall to start, that variable's value must be set to
|
|
|
|
'Yes'. This change accomplishes two things:
|
|
|
|
|
|
|
|
a) It prevents Shorewall from being started prematurely by the
|
|
|
|
user's initialization scripts.
|
|
|
|
|
|
|
|
b) It causes /etc/shorewall/shorewall.conf to be modified so that
|
|
|
|
it won't be replaced by upgrades using RPM.
|
2004-08-06 17:35:05 +02:00
|
|
|
|
|
|
|
7) Some additional support has been added for the 2.6 Kernel IPSEC
|
|
|
|
implementation. To use this support, you must have installed the
|
2004-10-12 18:38:46 +02:00
|
|
|
IPSEC policy match patch and the four IPSEC/Netfilter patches
|
|
|
|
from Patch-0-Matic-ng. The policy match patch affects both your
|
|
|
|
kernel and iptables.
|
2004-08-06 17:35:05 +02:00
|
|
|
|
2004-08-19 00:29:09 +02:00
|
|
|
There are two ways to specify that IPSEC is to be used when
|
|
|
|
communicating with a set of hosts; both methods involve the new
|
|
|
|
/etc/shorewall/ipsec file:
|
|
|
|
|
|
|
|
a) If encrypted communication is used with all hosts in a zone,
|
|
|
|
then you can designate the zone as an "ipsec" zone by placing
|
|
|
|
'Yes" in the IPSEC ONLY column in the /etc/shorewall/ipsec:
|
|
|
|
|
2004-10-15 20:46:27 +02:00
|
|
|
#ZONE IPSEC OPTIONS ...
|
2004-08-19 00:29:09 +02:00
|
|
|
# ONLY
|
|
|
|
vpn Yes
|
|
|
|
|
|
|
|
The hosts in the zone (if any) must be specified in
|
|
|
|
/etc/shorewall/hosts but you do not need to specify the 'ipsec'
|
|
|
|
option on the entries in that file (see below).
|
|
|
|
|
|
|
|
Dynamic zones involving IPSEC must use that technique.
|
2004-08-06 17:35:05 +02:00
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
Under 2.4 Kernel FreeS/Wan:
|
|
|
|
|
|
|
|
/etc/shorewall/zones:
|
|
|
|
|
|
|
|
net Net The big bad Internet
|
|
|
|
vpn VPN Remote Network
|
|
|
|
|
|
|
|
/etc/shorewall/interfaces:
|
|
|
|
|
|
|
|
net eth0 ...
|
|
|
|
vpn ipsec0 ...
|
|
|
|
|
|
|
|
Under 2.6 Kernel with this new support:
|
|
|
|
|
2004-08-19 00:29:09 +02:00
|
|
|
/etc/shorewall/zones:
|
|
|
|
|
|
|
|
net Net The big bad Internet
|
|
|
|
vpn VPN Remote Network
|
|
|
|
|
|
|
|
/etc/shorewall/interfaces:
|
|
|
|
|
|
|
|
net eth0 ...
|
|
|
|
|
|
|
|
/etc/shorewall/hosts:
|
|
|
|
|
|
|
|
vpn eth0:0.0.0.0/0
|
|
|
|
|
|
|
|
/etc/shorewall/ipsec
|
|
|
|
|
|
|
|
vpn Yes
|
|
|
|
|
|
|
|
b) If only part of the hosts in a zone require encrypted
|
|
|
|
communication, you may use of the new 'ipsec' option in
|
|
|
|
/etc/shorewall/hosts to designate those hosts.
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
Under 2.4 Kernel FreeS/Wan:
|
|
|
|
|
|
|
|
/etc/shorewall/zones:
|
|
|
|
|
|
|
|
net Net The big bad Internet
|
|
|
|
loc Local Extended local zone
|
|
|
|
|
|
|
|
/etc/shorewall/interfaces:
|
|
|
|
|
|
|
|
net eth0 ...
|
|
|
|
loc eth1 ...
|
|
|
|
loc ipsec0 ...
|
|
|
|
|
|
|
|
Under 2.6 Kernel with this new support:
|
|
|
|
|
|
|
|
/etc/shorewall/zones:
|
2004-08-06 17:35:05 +02:00
|
|
|
|
2004-08-19 00:29:09 +02:00
|
|
|
net Net The big bad Internet
|
|
|
|
vpn VPN Remote Network
|
2004-08-06 17:35:05 +02:00
|
|
|
|
|
|
|
/etc/shorewall/interfaces:
|
|
|
|
|
|
|
|
net eth0 ...
|
2004-08-19 00:29:09 +02:00
|
|
|
loc eth1 ...
|
2004-08-06 17:35:05 +02:00
|
|
|
|
|
|
|
/etc/shorewall/hosts:
|
|
|
|
|
2004-08-19 00:29:09 +02:00
|
|
|
vpn eth0:0.0.0.0/0 ipsec,...
|
|
|
|
|
|
|
|
Regardless of which technique you choose, you can specify
|
|
|
|
additional SA options for the zone in the /etc/shorewall/ipsec
|
|
|
|
entry.
|
|
|
|
|
2004-08-20 17:37:56 +02:00
|
|
|
The OPTIONS, IN OPTIONS and OUT OPTIONS columns specify the
|
2004-10-15 22:00:48 +02:00
|
|
|
input-output, input and output characteristics of the security
|
2004-08-20 17:37:56 +02:00
|
|
|
policies to be used to decrypt (input) or encrypt (output) traffic
|
|
|
|
to/from the zone.
|
2004-08-19 00:29:09 +02:00
|
|
|
|
|
|
|
The available options are:
|
2004-08-14 20:39:09 +02:00
|
|
|
|
2004-08-21 23:47:16 +02:00
|
|
|
reqid[!]=<number> where <number> is specified using setkey(8) using
|
2004-08-19 00:29:09 +02:00
|
|
|
the 'unique:<number>' option for the SPD level.
|
|
|
|
|
2004-08-21 23:47:16 +02:00
|
|
|
spi[!]=<number> where <number> is the SPI of the SA. Since
|
|
|
|
different SAs are used to encrypt and decrypt traffic, this
|
|
|
|
option should only be listed in the IN OPTIONS and OUT OPTIONS
|
|
|
|
columns.
|
2004-08-19 00:29:09 +02:00
|
|
|
|
2004-10-15 22:00:48 +02:00
|
|
|
proto[!]=ah|esp|ipcomp
|
|
|
|
|
|
|
|
mss=<number> (sets the MSS value in TCP SYN packets and is not
|
|
|
|
related to policy matching)
|
2004-08-19 00:29:09 +02:00
|
|
|
|
2004-08-21 23:47:16 +02:00
|
|
|
mode[!]=transport|tunnel
|
2004-08-19 00:29:09 +02:00
|
|
|
|
2004-08-21 23:47:16 +02:00
|
|
|
tunnel-src[!]=<address>[/<mask>] (only available with mode=tunnel)
|
2004-08-19 00:29:09 +02:00
|
|
|
|
2004-08-21 23:47:16 +02:00
|
|
|
tunnel-dst[!]=<address>[/<mask>] (only available with
|
|
|
|
mode=tunnel). Because tunnel source and destination are
|
|
|
|
dependent on the direction of the traffic, these options
|
|
|
|
should only appear in the IN OPTIONS and OUT OPTIONS columns.
|
|
|
|
|
|
|
|
strict (if specified, packets must match all policies;
|
2004-10-12 18:38:46 +02:00
|
|
|
policies are delimited by 'next').
|
2004-08-21 23:47:16 +02:00
|
|
|
|
|
|
|
next (only available with strict)
|
2004-08-19 00:29:09 +02:00
|
|
|
|
|
|
|
Examples:
|
|
|
|
|
2004-10-15 20:46:27 +02:00
|
|
|
#ZONE IPSEC OPTIONS IN OUT...
|
2004-08-20 17:37:56 +02:00
|
|
|
# ONLY OPTIONS OPTIONS
|
|
|
|
vpn Yes mode=tunnel,proto=esp spi=1000 spi=1001
|
2004-08-19 00:29:09 +02:00
|
|
|
loc No reqid=44,mode=transport
|
2004-10-15 20:46:27 +02:00
|
|
|
|
2004-08-14 20:39:09 +02:00
|
|
|
The /etc/shorewall/masq file has a new IPSEC column added. If you
|
|
|
|
specify Yes or yes in that column then the unencrypted packets will
|
|
|
|
have their source address changed. Otherwise, the unencrypted
|
2004-08-19 00:29:09 +02:00
|
|
|
packets will not have their source addresses changed. This column
|
|
|
|
may also contain a comma-separated list of the options specified
|
|
|
|
above in which case only those packets that will be encrypted
|
|
|
|
by an SA matching the given options will have their source address
|
|
|
|
changed.
|
|
|
|
|
2004-08-14 21:03:10 +02:00
|
|
|
8) To improve interoperability, tunnels of type 'ipsec' no longer
|
2004-09-14 00:16:15 +02:00
|
|
|
enforce the use of source port 500 for ISAKMP and OpenVPN
|
|
|
|
tunnels no longer enforce use of the specified port as both the
|
|
|
|
source and destination ports.
|
2004-08-14 22:44:15 +02:00
|
|
|
|
|
|
|
9) A new 'allowBcast' builtin action has been added -- it silently
|
2004-08-20 00:22:49 +02:00
|
|
|
allows broadcasts and multicasts.
|
|
|
|
|
|
|
|
10) The -c option in /sbin/shorewall commands is now deprecated. The
|
|
|
|
commands where -c was previously allowed now permit you to specify
|
|
|
|
a configuration directory after the command:
|
|
|
|
|
|
|
|
shorewall check [ <configuration-directory> ]
|
|
|
|
shorewall restart [ <configuration-directory> ]
|
|
|
|
shorewall start [ <configuration-directory> ]
|
|
|
|
|
2004-08-26 22:59:39 +02:00
|
|
|
11) Normally, when SNAT or MASQUERADE is applied to a tcp or udp
|
|
|
|
connection, Netfilter attempts to retain the source port
|
|
|
|
number. If it has to change to port number to avoid
|
|
|
|
<source address>,<source port> conflicts, it tries to do so
|
|
|
|
within port ranges ( < 512, 512-1023, and > 1023). You may
|
|
|
|
now specify an explicit range of source ports to be used
|
|
|
|
by following the address or address range (if any) in the
|
|
|
|
ADDRESS column with ":" and a port range in the format
|
|
|
|
<low-port>-<high-port>. You must specify either "tcp" or
|
|
|
|
"udp" in the PROTO column.
|
|
|
|
|
|
|
|
Examples 1 -- MASQUERADE with tcp source ports 4000-5000:
|
|
|
|
|
|
|
|
#INTERFACE SUBNET ADDRESS PROTO
|
|
|
|
eth0 192.168.1.0/24 :4000-5000 tcp
|
|
|
|
|
|
|
|
Example 2 -- SNAT with udp source ports 7000-8000:
|
|
|
|
|
|
|
|
#INTERFACE SUBNET ADDRESS PROTO
|
|
|
|
eth0 10.0.0.0/8 192.0.2.44:7000-8000 udp
|
|
|
|
|
2004-08-28 00:16:22 +02:00
|
|
|
12) You may now account by user/group ID for outbound traffic from the
|
|
|
|
firewall itself with entries in /etc/shorewall/accounting. Such
|
|
|
|
accounting rules must be placed in the OUTPUT chain.
|
|
|
|
|
|
|
|
See the comments at the top of /etc/shorewall/accounting for
|
|
|
|
details.
|
|
|
|
|
2004-09-06 01:43:08 +02:00
|
|
|
13) Shorewall now verifies that your kernel and iptables have physdev
|
|
|
|
match support if BRIDGING=Yes in shorewall.conf.
|
2004-09-07 23:51:02 +02:00
|
|
|
|
2004-09-08 20:46:57 +02:00
|
|
|
14) Beginning with this release, if your kernel and iptables have
|
|
|
|
iprange match support (see the output from "shorewall check"), then
|
|
|
|
with the exception of the /etc/shorewall/netmap file, anywhere that
|
|
|
|
a network address may appear an IP address range of the form <low
|
|
|
|
address>-<high address> may also appear.
|
2004-09-08 22:13:31 +02:00
|
|
|
|
|
|
|
15) Support has been added for the iptables CLASSIFY target. That
|
|
|
|
target allows you to classify packets for traffic shaping directly
|
2004-10-12 18:38:46 +02:00
|
|
|
rather than indirectly through fwmark. Simply enter the
|
2004-09-08 22:13:31 +02:00
|
|
|
<major>:<minor> classification in the first column of
|
|
|
|
/etc/shorewall/tcrules:
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
#MARK/ SOURCE DEST PROTO PORT(S)
|
|
|
|
#CLASSIFY
|
2004-11-04 22:35:56 +01:00
|
|
|
1:30 - eth0 tcp 25
|
|
|
|
|
|
|
|
Note that when using this form of rule, it is acceptable to include
|
|
|
|
the name of an interface in the DEST column.
|
2004-09-08 22:13:31 +02:00
|
|
|
|
|
|
|
Marking using the CLASSIFY target always occurs in the POSTROUTING
|
|
|
|
chain of the mangle table and is not affected by the setting of
|
|
|
|
MARK_IN_FORWARD_CHAIN in shorewall.conf.
|
2004-09-11 18:16:34 +02:00
|
|
|
|
|
|
|
16) During "shorewall start", IP addresses to be added as a consequence
|
|
|
|
of ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes are quietly deleted
|
|
|
|
when /etc/shorewall/nat and /etc/shorewall/masq are processed then
|
|
|
|
the are re-added later. This is done to help ensure that the
|
|
|
|
addresses can be added with the specified labels but can have
|
|
|
|
the undesirable side effect of causing routes to be quietly
|
|
|
|
deleted. A new RETAIN_ALIASES option has been added to
|
|
|
|
shorewall.conf; when this option is set to Yes, existing addresses
|
|
|
|
will not be deleted. Regardless of the setting of RETAIN_ALIASES,
|
|
|
|
addresses added during "shorewall start" are still deleted at a
|
|
|
|
subsequent "shorewall stop" or "shorewall restart".
|
|
|
|
|
2004-09-15 22:04:36 +02:00
|
|
|
17) Users with a large black list (from /etc/shorewall/blacklist) may
|
|
|
|
want to set the new DELAYBLACKLISTLOAD option in
|
|
|
|
shorewall.conf. When DELAYBLACKLISTLOAD=Yes, Shorewall will
|
|
|
|
enable new connections before loading the blacklist rules. While
|
|
|
|
this may allow connections from blacklisted hosts to slip by during
|
|
|
|
construction of the blacklist, it can substantially reduce the time
|
|
|
|
that all new connections are disabled during "shorewall [re]start".
|
|
|
|
|
2004-09-25 19:18:25 +02:00
|
|
|
18) Using the default LOGFORMAT, chain names longer than 11 characters
|
|
|
|
(such as in user-defined actions) may result in log prefix
|
|
|
|
truncation. A new shorewall.conf action LOGTAGONLY has been added
|
|
|
|
to deal with this problem. When LOGTAGONLY=Yes, logging rules that
|
|
|
|
specify a log tag will substitute the tag for the chain name in the
|
|
|
|
log prefix.
|
2004-09-15 22:04:36 +02:00
|
|
|
|
2004-09-25 19:18:25 +02:00
|
|
|
Example -- file /etc/shorewall/action.thisisaverylogactionname:
|
|
|
|
|
|
|
|
Rule:
|
|
|
|
|
|
|
|
DROP:info:ftp 0.0.0.0/0 0.0.0.0/0 tcp 21
|
|
|
|
|
|
|
|
Log prefix with LOGTAGONLY=No:
|
|
|
|
|
|
|
|
Shorewall:thisisaverylongacti
|
|
|
|
|
|
|
|
Log prefix with LOGTAGONLY=Yes:
|
|
|
|
|
|
|
|
Shorewall:ftp:DROP
|
2004-10-03 02:44:12 +02:00
|
|
|
|
|
|
|
19) Shorewall now resets the 'accept_source_route' flag for all
|
|
|
|
interfaces. If you wish to accept source routing on an interface,
|
|
|
|
you must specify the new 'sourceroute' interface option in
|
|
|
|
/etc/shorewall/interfaces.
|
2004-10-08 00:56:35 +02:00
|
|
|
|
|
|
|
20) The default Drop and Reject actions now invoke the new standard
|
|
|
|
action 'AllowICMPs'. This new action accepts critical ICMP types:
|
|
|
|
|
|
|
|
Type 3 code 4 (fragmentation needed)
|
|
|
|
Type 11 (TTL exceeded)
|
2004-10-12 18:38:46 +02:00
|
|
|
|
|
|
|
21) Explicit control over the kernel's Martian logging is now provided
|
|
|
|
using the new 'logmartians' interface option. If you include
|
|
|
|
'logmartians' in the interface option list then logging of Martian
|
|
|
|
packets on will be enabled on the specified interface.
|
|
|
|
If you wish to globally enable martian logging, you can set
|
2004-10-24 23:25:28 +02:00
|
|
|
LOG_MARTIANS=Yes in shorewall.conf.
|
2004-10-12 18:38:46 +02:00
|
|
|
|
2004-10-13 02:42:26 +02:00
|
|
|
22) You may now cause Shorewall to use the '--set-mss' option of the
|
|
|
|
TCPMSS target. In other words, you can cause Shorewall to set the
|
|
|
|
MSS field of SYN packets passing through the firewall to the value
|
2004-10-13 19:05:25 +02:00
|
|
|
you specify. This feature extends the existing CLAMPMSS option in
|
|
|
|
/etc/shorewall/shorewall.conf by allowing that option to have a
|
|
|
|
numeric value as well as the values "Yes" and "No".
|
2004-10-13 02:42:26 +02:00
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
CLAMPMSS=1400
|
2004-10-17 21:46:31 +02:00
|
|
|
|
|
|
|
23) Shorewall now includes support for the ipp2p match facility. This
|
|
|
|
is a departure from my usual policy in that the ipp2p match
|
|
|
|
facility is included in Patch-O-Matic-NG and is unlikely to ever be
|
|
|
|
included in the kernel.org source tree. Questions about how to
|
|
|
|
install the patch or how to build your kernel and/or iptables
|
|
|
|
should not be posted on the Shorewall mailing lists.
|
|
|
|
|
|
|
|
In the following files, the "PROTO" or "PROTOCOL" column may
|
|
|
|
contain "ipp2p":
|
|
|
|
|
|
|
|
/etc/shorewall/rules
|
|
|
|
/etc/shorewall/tcrules
|
|
|
|
/etc/shorewall/accounting
|
|
|
|
|
|
|
|
When the PROTO or PROTOCOL column contains "ipp2p" then the DEST
|
|
|
|
PORT(S) or PORT(S) column may contain a recognized ipp2p option;
|
|
|
|
for a list of the options and their meaning, at a root prompt:
|
|
|
|
|
|
|
|
iptables -m ipp2p --help
|
|
|
|
|
|
|
|
You must not include the leading "--" on the option; Shorewall will
|
|
|
|
supply those characters for you. If you do not include an option
|
|
|
|
then "ipp2p" is assumed (Shorewall will generate "-m ipp2p
|
|
|
|
--ipp2p").
|
|
|
|
|
|
|
|
24) Shorewall now has support for the CONNMARK target from iptables.
|
|
|
|
See the /etc/shorewall/tcrules file for details.
|
|
|
|
|
2004-10-24 20:53:38 +02:00
|
|
|
25) A new debugging option LOGALLNEW has been added to
|
|
|
|
shorewall.conf. When set to a log level, this option causes
|
|
|
|
Shorewall to generaate a logging rule as the first rule in each
|
|
|
|
builtin chain.
|
|
|
|
|
|
|
|
- The table name is used as the chain name in the log prefix.
|
|
|
|
- The chain name is used as the target in the log prefix.
|
|
|
|
|
|
|
|
Example: Using the default LOGFORMAT, the log prefix for logging
|
|
|
|
from the nat table's PREROUTING chain is:
|
|
|
|
|
|
|
|
Shorewall:nat:PREROUTING
|
|
|
|
|
|
|
|
IMPORTANT: There is no rate limiting on these logging rules so
|
|
|
|
use LOGALLNEW at your own risk; it may cause high CPU and disk
|
|
|
|
utilization and you may not be able to control your firewall after
|
|
|
|
you enable this option.
|
|
|
|
|
|
|
|
DANGER: DO NOT USE THIS OPTION IF THE RESULTING LOG MESSAGES WILL
|
|
|
|
BE SENT TO ANOTHER SYSTEM.
|
2004-10-26 17:26:13 +02:00
|
|
|
|
|
|
|
26) The SUBNET column in /etc/shorewall/rfc1918 has been renamed
|
|
|
|
SUBNETS and it is now possible to specify a list of addresses in
|
|
|
|
that column.
|
2004-11-16 16:04:34 +01:00
|
|
|
|
|
|
|
27) The AllowNNTP action now also allows NNTP over SSL/TLS (NNTPS).
|
2004-11-25 00:36:26 +01:00
|
|
|
|
|
|
|
28) For consistency, the CLIENT PORT(S) column in the tcrules file has
|
|
|
|
been renamed SOURCE PORT(S).
|
2004-11-26 19:44:42 +01:00
|
|
|
|
|
|
|
29) The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is now shown
|
|
|
|
in the output of "shorewall status".
|
|
|
|
|
|
|
|
30) A new IPTABLES option has been added to shorewall.conf. IPTABLES
|
|
|
|
can be used to designate the iptables executable to be used by
|
|
|
|
Shorewall. If not specified, the iptables executable determined by
|
|
|
|
the PATH setting is used.
|
2004-11-27 20:44:32 +01:00
|
|
|
|
2004-11-28 18:32:00 +01:00
|
|
|
31) You can now use the "shorewall show zones" command to display the
|
|
|
|
current contents of the zones. This is particularly useful if you
|
|
|
|
use dynamic zones (DYNAMIC_ZONES=Yes in shorewall.conf).
|
2004-11-27 20:44:32 +01:00
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
ursa:/etc/shorewall # shorewall show zones
|
|
|
|
Shorewall-2.2.0-Beta7 Zones at ursa - Sat Nov 27 11:18:25 PST 2004
|
|
|
|
|
|
|
|
loc
|
|
|
|
eth0:192.168.1.0/24
|
|
|
|
eth1:1.2.3.4
|
|
|
|
net
|
|
|
|
eth0:0.0.0.0/0
|
|
|
|
WiFi
|
|
|
|
eth1:0.0.0.0/0
|
|
|
|
sec
|
|
|
|
eth1:0.0.0.0/0
|
|
|
|
|
|
|
|
ursa:/etc/shorewall #
|
|
|
|
|
2004-11-29 16:05:16 +01:00
|
|
|
32) Variable expansion may now be used with the INCLUDE directive.
|
2004-11-27 20:44:32 +01:00
|
|
|
|
2004-11-29 16:05:16 +01:00
|
|
|
Example:
|
|
|
|
|
|
|
|
/etc/shorewall/params
|
|
|
|
|
|
|
|
FILE=/etc/foo/bar
|
|
|
|
|
|
|
|
Any other config file:
|
|
|
|
|
|
|
|
INCLUDE $FILE
|
2004-12-03 21:35:21 +01:00
|
|
|
|
|
|
|
33) The output of "shorewall status" now includes the results of "ip
|
|
|
|
-stat link ls". This helps diagnose performance problems caused by
|
|
|
|
link errors.
|
2004-12-03 23:00:31 +01:00
|
|
|
|
|
|
|
34) Previously, when rate-limiting was specified in
|
|
|
|
/etc/shorewall/policy (LIMIT:BURST column), any traffic which
|
|
|
|
exceeded the specified rate was silently dropped. Now, if a log
|
|
|
|
level is given in the entry (LEVEL column) then drops are logged at
|
|
|
|
that level at a rate of 5/min with a burst of 5.
|
2004-12-07 17:31:48 +01:00
|
|
|
|
|
|
|
35) Recent 2.6 kernels include code that evaluates TCP packets based on
|
|
|
|
TCP Window analysis. This can cause packets that were previously
|
|
|
|
classified as NEW or ESTABLISHED to be classified as INVALID.
|
|
|
|
|
|
|
|
The new kernel code can be disabled by including this command in
|
|
|
|
your /etc/shorewall/init file:
|
|
|
|
|
|
|
|
echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal
|
|
|
|
|
|
|
|
Additional kernel logging about INVALID TCP packets may be
|
|
|
|
obtained by adding this command to /etc/shorewall/init:
|
|
|
|
|
|
|
|
echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid
|
|
|
|
|
|
|
|
Traditionally, Shorewall has dropped INVALID TCP packets early. The
|
|
|
|
new DROPINVALID option allows INVALID packets to be passed through
|
|
|
|
the normal rules chains by setting DROPINVALID=No.
|
|
|
|
|
|
|
|
If not specified or if specified as empty (e.g., DROPINVALID="")
|
|
|
|
then DROPINVALID=Yes is assumed.
|
2004-12-08 21:00:03 +01:00
|
|
|
|
|
|
|
36) The "shorewall add" and "shorewall delete" commands now accept a
|
|
|
|
list of hosts to add or delete.
|
|
|
|
|
|
|
|
Examples:
|
|
|
|
|
|
|
|
shorewall add eth1:1.2.3.4 eth1:2.3.4.5 z12
|
|
|
|
shorewall delete eth1:1.2.3.4 eth1:2.3.4.5 z12
|
|
|
|
|
2004-12-11 16:46:37 +01:00
|
|
|
The above commands may also be written:
|
|
|
|
|
|
|
|
shorewall add eth1:1.2.3.4,2.3.4.5 z12
|
|
|
|
shorewall delete eth1:1.2.3.4,2.3.4.5 z12
|
|
|
|
|
2004-12-25 23:37:26 +01:00
|
|
|
37) TCP OpenVPN tunnels are now supported using the 'openvpn' tunnel
|
2004-12-14 17:11:49 +01:00
|
|
|
type. OpenVPN entries in /etc/shorewall/tunnels have this format:
|
|
|
|
|
|
|
|
openvpn[:{tcp|udp}][:<port>] <zone> <gateway>
|
|
|
|
|
|
|
|
Examples:
|
|
|
|
|
2004-12-19 21:38:52 +01:00
|
|
|
openvpn:tcp net 1.2.3.4 # TCP tunnel on port 1194
|
2004-12-14 17:11:49 +01:00
|
|
|
openvpn:3344 net 1.2.3.4 # UDP on port 3344
|
|
|
|
openvpn:tcp:4455 net 1.2.3.4 # TCP on port 4455
|
2004-12-19 17:52:13 +01:00
|
|
|
|
2004-12-25 23:37:26 +01:00
|
|
|
38) A new 'ipsecvpn' script is included in the tarball and in the
|
2004-12-19 17:52:13 +01:00
|
|
|
RPM. The RPM installs the file in the Documentation directory
|
|
|
|
(/usr/share/doc/packages/shorewall-2.2.0-0RC1).
|
|
|
|
|
|
|
|
This script is intended for use on Roadwarrior laptops for
|
|
|
|
establishing an IPSEC SA to/from remote networks. The script has
|
|
|
|
some limitations:
|
|
|
|
|
|
|
|
- Only one instance of the script may be used at a time.
|
|
|
|
- Only the first SPD accessed will be instantiated at the remote
|
|
|
|
gateway. So while the script creates SPDs to/from the remote
|
|
|
|
gateway and each network listed in the NETWORKS setting at the
|
|
|
|
front of the script, only one of these may be used at a time.
|
|
|
|
|
2004-12-25 23:37:26 +01:00
|
|
|
39) The IANA has recently registered port 1194 for use by OpenVPN. In
|
|
|
|
previous versions of Shorewall (and OpenVPN), the default port was
|
|
|
|
5000 but has been changed to 1194 to conform to the new OpenVPN
|
|
|
|
default.
|