Displaying 20 results from an estimated 30000 matches similar to: "One more thing about Multi-ISP feature"
2004 Nov 02
3
Shorewall 2.2.0 Beta 2
http://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta2
ftp://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta2
Problems Corrected:
1. The "shorewall check" command results in the (harmless) error
message:
/usr/share/shorewall/firewall: line 2753:
check_dupliate_zones: command not found
2. The
2005 Jun 06
1
iptables bug results in confusion
The current thread on the User''s List entitled "Multi-ISP in 2.4.0" includes
the following tcrules file:
############################################################################
##
#MARK SOURCE DEST PROTO PORT(S) CLIENT USER
TEST
# PORT(S)
201:P eth2 ppp1
2005 Mar 15
2
New feature for Shorewall 2.2.3
The following is taken from the Release notes for 2.2.3 (which will be
released in a month or so).
2) There has been ongoing confusion about how the
/etc/shorewall/routestopped file works. People understand how it
works with the ''shorewall stop'' command but when they read that
''shorewall restart'' is logically equivalent to ''shorewall
2006 Mar 27
0
Re: Re: multiple isp. masqueraded machines somtimes work and somet
Why ping google ???
you should either ping your assigned external ip address ( make your config dhcp for your external ip address even if it is static )
( If your dsl link is up you sould have an address if not you should not )
If for some reson you cannot do that, ping your isp''s default gw or someone closer. With google you never know what is going on.
I do something similar with -m
2007 Aug 21
10
Bug in Multi-ISP support
In helping a user on IRC today, I was dismayed to find that a bug that
was supposedly fixed in Shorewall 3.4.4 was not fixed. Furthermore, I
found that the bug is present as far back as 3.2.6 (I didn''t look back
further since 3.2.6 was the release where the user (re-) discovered the
bug.
If HIGH_ROUTE_MARKS=No, then PREROUTING and OUTPUT marking rules are
behaving as if TC_EXPERT=Yes was
2007 Aug 21
10
Bug in Multi-ISP support
In helping a user on IRC today, I was dismayed to find that a bug that
was supposedly fixed in Shorewall 3.4.4 was not fixed. Furthermore, I
found that the bug is present as far back as 3.2.6 (I didn''t look back
further since 3.2.6 was the release where the user (re-) discovered the
bug.
If HIGH_ROUTE_MARKS=No, then PREROUTING and OUTPUT marking rules are
behaving as if TC_EXPERT=Yes was
2007 Nov 28
2
[Fwd: Re: Port 3001 still have problem]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
As I pointed out to Wilson in a private message, this appears to show
that no other connection requests (other than port 3000) are being sent
from the client to the server (or at least no other connection requests
are being received by the Shorewall box).
Wilson: Are you sure that the client is supposed to open port 3001 on
the server and not the
2004 Sep 29
0
Re: Shorewall-users Digest, Vol 22, Issue 65
Hi
I have 2nic firewall . I had to open some ranges of udp and tcp ports . I
faced a problem that although all the ports are open Some functionality was
not working . Any body used shorewall with H323 Voip traffic DNATed . Any
help is appretiated .
Thanks
----- Original Message -----
From: <shorewall-users-request@lists.shorewall.net>
To: <shorewall-users@lists.shorewall.net>
Sent:
2005 May 17
1
Support for inbound traffic from multiple ISPs in CVS
The Shorewall2/ project in CVS contains my initial attempt to establish
correct routing for traffic forwarded from two different ISPs to
internal servers.
>From the release notes:
Shorewall 2.3.2 includes support for multiple Internet interfaces to
different ISPs. This feature is enabled by setting the "default"
option for each Internet interface in
2004 Sep 23
0
Fwd: RE: 2.6 kernel ipsec and shorewall
FYI...
---------- Forwarded Message ----------
Subject: RE: [Shorewall-users] 2.6 kernel ipsec and shorewall
Date: Thursday 23 September 2004 07:44
From: "Jonathan Schneider" <jon@clearconcepts.ca>
To: "''Tom Eastep''" <teastep@shorewall.net>
I must have been up too late working on this, looking at it the next day I
noticed I completely forgot
2005 Sep 20
0
Fwd: [PATCH] Another iptables-save buglet
FYI
This bug will prevent ''shorewall restore'' from working if you have "!<single
IP address>" in the ORIGINAL DEST column.
-Tom
---------- Forwarded Message ----------
Subject: [PATCH] Another iptables-save buglet
Date: Wednesday 14 September 2005 15:09
From: Tom Eastep <teastep@shorewall.net>
To: netfilter-devel@lists.netfilter.org
The conntrack
2005 Jan 03
1
RE: Outlook Web Access behind shorewall firewalldoesn''t work
Thanks for such a quick reply Tom!
Any suggestions then as to what I might do other than putting a second
nic in the SBS and opening it up for web access? I don''t like the idea,
but since MS SBS includes fireall that is actually what MS suggests.
Boyd
-----Original Message-----
From: Tom Eastep [mailto:teastep@shorewall.net]
Sent: January 3, 2005 3:05 PM
To: Shorewall Users
Cc: Boyd
2004 Nov 02
0
Shorewall 2.2.0 Beta 2
http://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta2
ftp://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta2
Problems Corrected:
1. The "shorewall check" command results in the (harmless) error
message:
/usr/share/shorewall/firewall: line 2753:
check_dupliate_zones: command not found
2. The
2006 Oct 19
1
Re: Tc rules Helpwith multiISP+ squid& squidguard...
I found that in my kernel config :
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
But no CONFIG_IP_ROUTE_MULTIPATH_CACHED.
-----Message
2005 Mar 30
1
RE: Shorewall and an inline IDS (snort-inlineorhogwash)
You are awesome!!!!
-----Original Message-----
From: shorewall-users-bounces@lists.shorewall.net
[mailto:shorewall-users-bounces@lists.shorewall.net] On Behalf Of Tom
Eastep
Sent: Wednesday, March 30, 2005 9:11 AM
To: Mailing List for Shorewall Users
Subject: Re: [Shorewall-users] Shorewall and an inline IDS
(snort-inlineorhogwash)
Tom Eastep wrote:
> Thibodeau, Jamie L. wrote:
>
2005 Mar 30
1
RE: Shorewall and an inline IDS(snort-inlineorhogwash)
Plus I would like to let you know that it works like a charm.
Snort can now see those packets.
-----Original Message-----
From: shorewall-users-bounces@lists.shorewall.net
[mailto:shorewall-users-bounces@lists.shorewall.net] On Behalf Of
Thibodeau, Jamie L.
Sent: Wednesday, March 30, 2005 9:25 AM
To: Mailing List for Shorewall Users
Subject: RE: [Shorewall-users] Shorewall and an inline
2004 Nov 09
1
Shorewall 2.2.0 Beta 3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
http://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta3
ftp://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta3
Problems Corrected:
1. Missing ''#'' in the rfc1918 file has been corrected.
2. The INSTALL file now includes special instructions for Slackware
users.
New Features:
1. In CLASSIFY rules
2005 May 22
2
Shorewall 2.4.0 RC1
http://shorewall.net/pub/shorewall/2.4/shorewall-2.4.0-RC1/
ftp://shorewall.net/pub/shorewall/2.4/shorewall-2.4.0-RC1/
The release notes are in the download directory.
-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
2005 May 15
1
Shorewall 2.3.1
This is the latest development release and may be found at:
http://shorewall.net/pub/shorewall/2.3/shorewall-2.3.1
ftp://shorewall.net/pub/shorewall/2.3/shorewall-2.3.1
This release changes the way that SAVE_IPSETS=Yes works to try to make
it harder to shoot yourself in the foot. Read the release notes carefully.
In addition, there are two problems corrected:
1) A typo in the
2005 Feb 02
1
Shorewall 2.0.16
This release back-ports the DROPINVALID shorewall.conf option from 2.2.0.
1) 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