Hi, On a fresh install Debian system ( lenny ) shorewall 4.4.19.1 Trying to implement the old transparent proxy rule I''ve tried DNAT loc:vmbr0:+[!net_direct] dmz:10.0.21.12:3128 - +[!no_proxy_hosts] and it Gives an error "Invalid ORIGINAL DEST" while on an old system with shorewall 3.4.8 on it it passes OK. In my opinion the ORIG DESTINATION column Craves for ipsets. Regards Harry ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
Please pardon the top post but I am sending this from my IPad which I am not very good with yet. This is not a Shorewall restriction but is rather a restriction of ipsets Tom Sent from my iPad On Apr 27, 2011, at 12:54 PM, Harry Lachanas <grharry@freemail.gr> wrote:> Hi, > > On a fresh install > > Debian system ( lenny ) > > shorewall 4.4.19.1 > > Trying to implement the old transparent proxy rule > > I''ve tried > > DNAT loc:vmbr0:+[!net_direct] dmz:10.0.21.12:3128 - +[!no_proxy_hosts] > > and it Gives an error "Invalid ORIGINAL DEST" > > while on an old system with shorewall 3.4.8 on it it passes OK. > > In my opinion the ORIG DESTINATION column Craves for ipsets. > > Regards > Harry > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> This is not a Shorewall restriction but is rather a restriction of ipsets > >> while on an old system with shorewall 3.4.8 on it it passes OK. >>Can you read? ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> Can you read?Could you be more polite, please? Tom is one of the most helpful people in Internetland, and he doesn''t warrant such rudeness. ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On Apr 27, 2011, at 2:25 PM, Mr Dash Four <mr.dash.four@googlemail.com> wrote:> >> This is not a Shorewall restriction but is rather a restriction of ipsets >> >>> while on an old system with shorewall 3.4.8 on it it passes OK. >>> > Can you read? >I can read fine. But the OPs assertion that this worked in Shorewall 3 is nonsense. The syntax shown in his rule wasn''t introduced until Shorewall 4.4.14. -Tom ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> I can read fine. But the OPs assertion that this worked in Shorewall 3 is nonsense. The syntax shown in his rule wasn''t introduced until Shorewall 4.4.14. >In other words, nothing to do with ipsets "restrictions" then? ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
Sent from my iPad On Apr 27, 2011, at 3:39 PM, Mr Dash Four <mr.dash.four@googlemail.com> wrote:> >> I can read fine. But the OPs assertion that this worked in Shorewall 3 is nonsense. The syntax shown in his rule wasn''t introduced until Shorewall 4.4.14. >> > In other words, nothing to do with ipsets "restrictions" then? >As you well know, inset matches can match ''src'', ''dst'' or some combination. There is no ''origdst'' flag. So the ipset implementation does not support (and has never supported) matching on the original destination. Original destination is matched using the conn track match which doesn''t accept ipsets. So Shorewall 3 did not provide support for such a match and shorewall 4 doesn''t either. You were the one that requested the new syntax ([...]) that was implemented in Shorewall 4.4.14. So while using ipsets in the ORIGINAL DEST column would be cool, the only way to implement it currently would be with some packet marking hack. -Tom ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 04/28/2011 12:56 AM, Tom Eastep wrote:> On Apr 27, 2011, at 2:25 PM, Mr Dash Four<mr.dash.four@googlemail.com> wrote: > >>> This is not a Shorewall restriction but is rather a restriction of ipsets >>> >>>> while on an old system with shorewall 3.4.8 on it it passes OK. >>>> >> Can you read? >> > I can read fine. But the OPs assertion that this worked in Shorewall 3 is nonsense. The syntax shown in his rule wasn''t introduced until Shorewall 4.4.14. > > -TomTom, a) I am sorry about the syntax simplification ( I always try to express myself in a *non-nonsense* manner ). b) I know that It is Introduced in 4.4.14 ( I read the list for a decade almost ). c) I''ve stated that this rule *passes*. Well I am sorry I should have stated *"The similar rule passes"*. d) I am *not* a law professional that tries to defend his case. e) I rarely use the term *nonsense* for other people I find it kind of rude, offensive and aggressive. So the actual rule used for 3.4.8 is: #-------------------------------- DNAT loc:$LOCIF:!+net_direct,+noproxyhosts,+abusers dmz:$SQSRV:$PROXYPORT tcp 80 - !+no_squid_hosts,+no_squid_nets #-------------------------------- The variables used are self-explanatory while Shorewall version 3.4.8 Shorewall show nat indicates in the segment of interest Chain excl_9 (1 references) pkts bytes target prot opt in out source destination 2529 162K RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 set net_direct src 0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 set noproxyhosts src 0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 set abusers src 1 48 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 set no_squid_hosts dst 1 52 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 set no_squid_nets dst 12144 641K DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 to:10.0.173.5:3128 The rule is tested and it works ok So far. -------------------------------------------------------------------------------------------------------------- If wished I can provide a shorewall dump. Other than that I rest my case and speek no more. Regards Harry ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> On Apr 27, 2011, at 2:25 PM, Mr Dash Four<mr.dash.four@googlemail.com> wrote: > >>> This is not a Shorewall restriction but is rather a restriction of ipsets >>> >>>> while on an old system with shorewall 3.4.8 on it it passes OK. >>>> >> Can you read? >> > I can read fine. But the OPs assertion that this worked in Shorewall 3 is nonsense. The syntax shown in his rule wasn''t introduced until Shorewall 4.4.14. > > -Tom( Sorry for the previous HTML message ) Tom, a) I am sorry about the syntax simplification ( I always try to express myself in a *non-nonsense* manner ). b) I know that It is Introduced in 4.4.14 ( I read the list for a decade almost ). c) I''ve stated that this rule *passes*. Well I am sorry I should have stated *"The similar rule passes"*. d) I am *not* a law professional that tries to defend his case. e) I rarely use the term *nonsense* for other people I find it kind of rude, offensive and aggressive. So the actual rule used for 3.4.8 is: #-------------------------------- DNAT loc:$LOCIF:!+net_direct,+noproxyhosts,+abusers dmz:$SQSRV:$PROXYPORT tcp 80 - !+no_squid_hosts,+no_squid_nets #-------------------------------- The variables used are self-explanatory while Shorewall version 3.4.8 Shorewall show nat indicates in the segment of interest Chain excl_9 (1 references) pkts bytes target prot opt in out source destination 2529 162K RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 set net_direct src 0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 set noproxyhosts src 0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 set abusers src 1 48 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 set no_squid_hosts dst 1 52 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 set no_squid_nets dst 13506 711K DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 to:10.0.173.5:3128 -------------------------------------------------------------------------------------------------------------- The rule is tested and it works ok So far. If wished I can provide a shorewall dump. Other than that I rest my case and speek no more. Regards Harry ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On Apr 28, 2011, at 3:31 AM, Harry Lachanas <grharry@freemail.gr> wrote:>> On Apr 27, 2011, at 2:25 PM, Mr Dash Four<mr.dash.four@googlemail.com> wrote: >> >>>> This is not a Shorewall restriction but is rather a restriction of ipsets >>>> >>>>> while on an old system with shorewall 3.4.8 on it it passes OK. >>>>> >>> Can you read? >>> >> I can read fine. But the OPs assertion that this worked in Shorewall 3 is nonsense. The syntax shown in his rule wasn''t introduced until Shorewall 4.4.14. >> >> -Tom > ( Sorry for the previous HTML message ) > > Tom, > a) I am sorry about the syntax simplification ( I always try to express myself in a *non-nonsense* manner ). > b) I know that It is Introduced in 4.4.14 ( I read the list for a decade almost ). > c) I''ve stated that this rule *passes*. Well I am sorry I should have stated *"The similar rule passes"*. > d) I am *not* a law professional that tries to defend his case. > e) I rarely use the term *nonsense* for other people I find it kind of rude, offensive and aggressive. > > > So the actual rule used for 3.4.8 is: > > #-------------------------------- > > DNAT loc:$LOCIF:!+net_direct,+noproxyhosts,+abusers dmz:$SQSRV:$PROXYPORT tcp 80 - !+no_squid_hosts,+no_squid_nets > > #-------------------------------- > > The variables used are self-explanatory > > while > > Shorewall version > 3.4.8 > > Shorewall show nat > indicates in the segment of interest > > Chain excl_9 (1 references) > pkts bytes target prot opt in out source destination > 2529 162K RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 set net_direct src > 0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 set noproxyhosts src > 0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 set abusers src > 1 48 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 set no_squid_hosts dst > 1 52 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 set no_squid_nets dst > 13506 711K DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 to:10.0.173.5:3128 > -------------------------------------------------------------------------------------------------------------- > > The rule is tested and it works ok So far. > If wished I can provide a shorewall dump. > Other than that > I rest my case and speek no more. >I stand humbly corrected and I''ll see what I can do about restoring that functionality in Shorewall 4.4.19. -Tom ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> I stand humbly corrected and I''ll see what I can do about restoring that functionality in Shorewall 4.4.19. >Thank you. Do you plan adding ipset support to (normal, not simple) accounting in Shorewall? ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 04/28/2011 07:07 AM, Tom Eastep wrote:> > I stand humbly corrected and I''ll see what I can do about restoring that functionality in Shorewall 4.4.19. >Here is a patch that restores the functionality. It applies (with possible offset) back at least as far as 4.4.11.6. As with the Shorewall 3.x implementation, the destination port is opened from the SOURCE zone to the specified server when an ipset name appears in the ORIGINAL DEST column of a DNAT rule. So for example: DNAT net loc:1.2.3.4 tcp 80 - +foo will also implicitly add this rule: ACCEPT net loc:1.2.3.4 tcp 80 You have been warned. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 04/28/2011 07:35 AM, Mr Dash Four wrote:> >> I stand humbly corrected and I''ll see what I can do about restoring that functionality in Shorewall 4.4.19. >> > Thank you. Do you plan adding ipset support to (normal, not simple) > accounting in Shorewall?Should be there already. What do you believe doesn''t work? -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
>> Thank you. Do you plan adding ipset support to (normal, not simple) >> accounting in Shorewall? >> > > Should be there already. What do you believe doesn''t work? >I also meant traffic shaping, apologies. My impression by reading the man pages on your web site (shorewall-accounting, shorewall-tcfilters) was that ipset is not supported. shorewall-accounting does not mention anything in any of the columns that ipset syntax is supported, shorewall-tcfilters states that ipset is definitely not supported (http://shorewall.net/traffic_shaping.htm - scroll down to the tcfilters section). I am not using the latest Shorewall version though - I am still on .14 as there are quite a few bugs present I did not have the time to report. I use complex, not simple accounting as well as traffic shaping (with between 1 to 3 ifbX interfaces on different boxes). ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 04/28/2011 08:30 AM, Mr Dash Four wrote:> > >>> Thank you. Do you plan adding ipset support to (normal, not simple) >>> accounting in Shorewall? >>> >> >> Should be there already. What do you believe doesn''t work? >> > I also meant traffic shaping, apologies. My impression by reading the > man pages on your web site (shorewall-accounting, shorewall-tcfilters)Do you mean shorewall-tcrules rather than shorewall-accounting? If so, that file does support ipsets; that''s an oversight in the manpage.> was that ipset is not supported. shorewall-accounting does not mention > anything in any of the columns that ipset syntax is supported, > shorewall-tcfilters states that ipset is definitely not supported > (http://shorewall.net/traffic_shaping.htm - scroll down to the tcfilters > section).Entries in the tcfilters file generate u32 filters which have no ipset support (nor will ever, IMO). They use (offset,mask,value) tuples applied to protocol headers and are not part of Netfilter at all. So tcrules are the only mechanism available that supports ipsets. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> Do you mean shorewall-tcrules rather than shorewall-accounting? If so, > that file does support ipsets; that''s an oversight in the manpage. >Both, actually. Even though I only use the "accounting" and "tcfilters" files - without ipset as I thought there was no ipset support.>> was that ipset is not supported. shorewall-accounting does not mention >> anything in any of the columns that ipset syntax is supported, >> shorewall-tcfilters states that ipset is definitely not supported >> (http://shorewall.net/traffic_shaping.htm - scroll down to the tcfilters >> section). >> > > Entries in the tcfilters file generate u32 filters which have no ipset > support (nor will ever, IMO). They use (offset,mask,value) tuples > applied to protocol headers and are not part of Netfilter at all. So > tcrules are the only mechanism available that supports ipsets. >I am no expert, but couldn''t ipsets be included at least in the SOURCE/DEST columns of ip addresses/subnets and port ranges, possibly the protocol too as the new generation of ipset could have a tuple of either (sub)net, port and protocol used? That is what I would need ipset to be used for - I am quite happy for the rest to remain as it is. Wouldn''t the use of tcrules force me to use simple traffic shaping instead? ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 04/28/2011 09:23 AM, Mr Dash Four wrote:>> Entries in the tcfilters file generate u32 filters which have no ipset >> support (nor will ever, IMO). They use (offset,mask,value) tuples >> applied to protocol headers and are not part of Netfilter at all. So >> tcrules are the only mechanism available that supports ipsets. >> > I am no expert, but couldn''t ipsets be included at least in the > SOURCE/DEST columns of ip addresses/subnets and port ranges, possibly > the protocol too as the new generation of ipset could have a tuple of > either (sub)net, port and protocol used?u32 filters don''t use iptables; they use ip.> That is what I would need ipset > to be used for - I am quite happy for the rest to remain as it is. > > Wouldn''t the use of tcrules force me to use simple traffic shaping instead?No. It is ''tcpri'' that is associated only with simple TC. But tcrules are also available in that case as well. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> No. It is ''tcpri'' that is associated only with simple TC. But tcrules > are also available in that case as well. >So, the choice for me then is using tcrules (and mindful therefore that it is last-match-wins scenario) with ipset, which is already supported. The same is valid for the accounting, is that right? ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On Apr 28, 2011, at 11:49 AM, Mr Dash Four <mr.dash.four@googlemail.com> wrote:> >> No. It is ''tcpri'' that is associated only with simple TC. But tcrules >> are also available in that case as well. >> > So, the choice for me then is using tcrules (and mindful therefore that > it is last-match-wins scenario) with ipset, which is already supported. > The same is valid for the accounting, is that right?That is correct. -Tom ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd