I did try installing the latest version of Ubuntu but that didn''t work
either. That didn''t seem to support CONNMARK either. Is CONNMARK
support the key? If I install Ubuntu then recompile the kernel to support
CONNMARK then should that work? Is there anything else that would need to be
supported to get this working?
Thanks
Si''
Sent from my iPhone
On 1 Oct 2010, at 21:45,
"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 (6 messages)>
> 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>
>
>
> On 9/30/10 3:59 PM, Simon Buckner wrote:
>> 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.
>>
>
> I''d be surprised if modern Shorewall Multi-ISP works at all on
this
> relic -- it doesn''t even have CONNMARK support.
>
> -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.
>>
> Is there any difference between ''shorewall show
connections'' when
> conntrack utility is used and when it is absent (and Shorewall uses
> /proc instead)?
>
>
>
> On 9/30/10 4:21 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.
>>>
>> Is there any difference between ''shorewall show
connections'' when
>> conntrack utility is used and when it is absent (and Shorewall uses
>> /proc instead)?
>
> There is currently no difference in the connection information.
>
> -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 Thu, 2010-09-30 at 12:56 -0400, Mark D. Montgomery II wrote:
>>
>> Ok Thanks.
>> That''s kind of the impression I got, but I wasn''t
sure.
>> It''s not a big deal since I can just toss up a UPnP server on
the
>> normal LAN somewhere and have it feed the media collection. I just
>> wanted to take advantage of the one built into MythTV if it was
>> possible.
>
> I think the problem here is that UPnP is a large spec which I
won''t even
> begin to tell you I understand but it covers many services including
> local LAN discovery of media services such as music and video (what OP
> is using) as well as gateway access provisioning (i.e. the crazy idea
> that networks on the LAN should tell the firewall what to let in and
> out).
>
> It''s a easy confusion with such a wide ranging spec under a single
> common term.
>
> b.
>
> I would like to proxy all http requests from my internal network to an
external proxy server that is outside my network. Unfortunately, I''m
having a bit of trouble figuring out the rule for doing that. If I run the
proxy on my firewall machine the following rules seem to work
>
> ACCEPT $FW net tcp www
> REDIRECT loc 3128 tcp www -
>
> but I have not been able to get the rule right to redirect to an external
system. Is this doable?
>
> thanks,
> Brent
>
>
------------------------------------------------------------------------------
> 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