Hi,
It is the multiple-ISP configuration. Most traffic should route out the primary
interface but certain traffic should route out the second interface.
Specifically and traffic to an IP address should go down the second which is a
private network.
Simon
Sent from my iPhone
On 30 Sep 2010, at 23:53,
"shorewall-users-request@lists.sourceforge.net"
<shorewall-users-request@lists.sourceforge.net> wrote:
> Send Shorewall-users mailing list submissions to
> shorewall-users@lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
> or, via email, send a message with subject or body ''help''
to
> shorewall-users-request@lists.sourceforge.net
>
> You can reach the person managing the list at
> shorewall-users-owner@lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Shorewall-users digest..."
> <Today''s Topics (7 messages)>
> Beta 3 is now available for testing.
>
> ---------------------------------------------------------------------------
> I. P R O B L E M S C O R R E C T E D I N T H I S R E L E A S E
>
----------------------------------------------------------------------------
>
> 1) Previously, Shorewall6 produced an untidy sequence of error
> messages when an attempt was made to start it on a system running a
> kernel older than 2.6.24:
>
> [root@localhost shorewall6]# shorewall6 start
> Compiling...
> Processing /etc/shorewall6/shorewall6.conf...
> Loading Modules...
> Compiling /etc/shorewall6/zones...
> ...
> Shorewall configuration compiled to /var/lib/shorewall6/.start
> ERROR: Shorewall6 requires Linux kernel 2.6.24 or later
> /usr/share/shorewall6/lib.common: line 73:
> [: -lt: unary operator expected
> ERROR: Shorewall6 requires Linux kernel 2.6.24 or later
> [root@localhost shorewall6]#
>
> This has been corrected so that a single ERROR message is
> generated.
>
> 2) Previously, an ipset name appearing in the /etc/shorewall/hosts
> file could be qualified with a list of ''src'' and/or
''dst'' enclosed
> in quotes. This was virtually guaranteed not to work since the set
> must match when used to verify both a packet source and a
> packet destination. Now, the following error is raised:
>
> ERROR: ipset name qualification is disallowed in this file
>
> As part of this change, the ipset name is now verified to begin
> with a letter and be composed of letters, digits, underscores
("_")
> and hyphens ("-").
>
>
----------------------------------------------------------------------------
> I I. K N O W N P R O B L E M S R E M A I N I N G
>
----------------------------------------------------------------------------
>
> 1) On systems running Upstart, shorewall-init cannot reliably secure
> the firewall before interfaces are brought up.
>
>
----------------------------------------------------------------------------
> I I I. N E W F E A T U R E S I N T H I S R E L E A S E
>
----------------------------------------------------------------------------
>
> 1) Shorewall now uses the ''conntrack'' utility for
''show connections''
> if that utility is installed. Going forward, the Netfilter team
> will be enhancing this interface rather than the /proc interface.
>
> 2) The CPU time required for optimization has been reduced by 2/3.
>
>
> --
> Tom Eastep \ When I die, I want to go like my Grandfather who
> Shoreline, \ died peacefully in his sleep. Not screaming like
> Washington, USA \ all of the passengers in his car
> http://shorewall.net \________________________________________________
>
>
>> shorewall save
>> shorewall restart
>>
> That, to me, seems the best alternative and I amended my init.d script
> to replace the existing reload with the above two statements. It works
> and I like it.
>
>
>
>
>> 1) Shorewall now uses the ''conntrack'' utility for
''show connections''
>> if that utility is installed. Going forward, the Netfilter team
>> will be enhancing this interface rather than the /proc interface.
>>
> Erm, No!
>
> The /proc interface will also be ''fixed'' to include
secctx field (i.e.
> secctx=system_u:object_r:packet_t:s0), which shows the correct SELinux
> context and the existing field secmark will be dropped.
>
>
>
> Hi,
> I''ll be able to double check tomorrow but I think it''s
running kernel-0-2.6.9-89.
>
> Simon
>
> -----Original Message-----
> From: Tom Eastep [mailto:teastep@shorewall.net]
> Sent: 30 September 2010 22:40
> To: shorewall-users@lists.sourceforge.net
> Subject: Re: [Shorewall-users] CentOS 4.8/Shorewall Problem
>
> On 9/30/10 1:55 PM, Simon Buckner wrote:
>
>> Please let me know what config details you want me to post and
I''ll
>> put them up?
>
> What kernel version does CentOS 4.8 use?
>
> -Tom
> --
> Tom Eastep \ When I die, I want to go like my Grandfather who
> Shoreline, \ died peacefully in his sleep. Not screaming like
> Washington, USA \ all of the passengers in his car
> http://shorewall.net \________________________________________________
>
>
>
> On 9/30/10 3:20 PM, Mr Dash Four wrote:
>>
>>> 1) Shorewall now uses the ''conntrack'' utility
for ''show connections''
>>> if that utility is installed. Going forward, the Netfilter team
>>> will be enhancing this interface rather than the /proc
interface.
>>>
>> Erm, No!
>>
>> The /proc interface will also be ''fixed'' to include
secctx field (i.e.
>> secctx=system_u:object_r:packet_t:s0), which shows the correct SELinux
>> context and the existing field secmark will be dropped.
>
> Jan Engelhardt (who I see as a possible successor to Patrick McHardy) is
> championing that general direction, irrespective of what happens with
> the current set of secmark issues.
>
> -Tom
> --
> Tom Eastep \ When I die, I want to go like my Grandfather who
> Shoreline, \ died peacefully in his sleep. Not screaming like
> Washington, USA \ all of the passengers in his car
> http://shorewall.net \________________________________________________
>
> On 9/30/10 3:35 PM, Simon Buckner wrote:
>> Hi,
>> I''ll be able to double check tomorrow but I think
it''s running kernel-0-2.6.9-89.
>
> I just installed it and it seems to be 2.6.9-89 but I''m in the
process
> of doing a ''yum update'' so that may change.
>
> You said that you are having problems "getting traffic to route down
the
> second NIC". What does that mean, exactly? Is this a multi-ISP
> configuration?
>
> -Tom
> --
> Tom Eastep \ When I die, I want to go like my Grandfather who
> Shoreline, \ died peacefully in his sleep. Not screaming like
> Washington, USA \ all of the passengers in his car
> http://shorewall.net \________________________________________________
>
>
>>>> 1) Shorewall now uses the ''conntrack''
utility for ''show connections''
>>>> if that utility is installed. Going forward, the Netfilter
team
>>>> will be enhancing this interface rather than the /proc
interface.
>>>>
>>>>
>>> Erm, No!
>>>
>>> The /proc interface will also be ''fixed'' to
include secctx field (i.e.
>>> secctx=system_u:object_r:packet_t:s0), which shows the correct
SELinux
>>> context and the existing field secmark will be dropped.
>>>
>>
>> Jan Engelhardt (who I see as a possible successor to Patrick McHardy)
is
>> championing that general direction, irrespective of what happens with
>> the current set of secmark issues.
>>
> I don''t know what direction Jan is ''championing''
with regards to the
> /proc interface, but the fact remains that, for the time being at least,
> the /proc interface will get the same treatment - as far as SELinux
> context is concerned - as the Netfilter interface (the point I''ve
made
> in my previous reply). You know about these discussions - you''ve
taken
> part in them on the netfilter mailing list.
>
>
>
------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> <Digest Footer>
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev