Hi Tom, hi list I upgraded my firewall system which included an update to shorewall-4.4.20.3-1.1.noarch (SuSE build service rpm). After that, DNAT seems to behave like DNAT- if the DNAT is directed to another DST port. Without port-translation it works as expected. Using this rules is not enough DNAT net loc0:$XEN0:22 tcp 52022 - $DSL_IP as this is logged: SW:net2loc0:DROP:IN=eth1 OUT=eth0 SRC=85.182.238.98 DST=192.168.1.2 LEN=60 TOS=0x00 PREC=0x00 TTL=57 ID=36614 DF PROTO=TCP SPT=43415 DPT=22 WINDOW=4380 RES=0x00 SYN URGP=0 Extending the rule to: DNAT net loc0:$XEN0:22 tcp 52022 - $DSL_IP SSH(ACCEPT) net loc0:$XEN0 solves the problem. Guess it''s a bug. Or did I miss something? Alex ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2
On Wed, 2011-07-06 at 22:20 +0200, Alexander Wilms wrote:> Hi Tom, hi list > > I upgraded my firewall system which included an update to shorewall-4.4.20.3-1.1.noarch (SuSE build service rpm). > > After that, DNAT seems to behave like DNAT- if the DNAT is directed to another DST port. Without port-translation it works as expected. > > Using this rules is not enough > DNAT net loc0:$XEN0:22 tcp 52022 - $DSL_IP > > as this is logged: > SW:net2loc0:DROP:IN=eth1 OUT=eth0 SRC=85.182.238.98 DST=192.168.1.2 LEN=60 TOS=0x00 PREC=0x00 TTL=57 ID=36614 DF PROTO=TCP SPT=43415 DPT=22 WINDOW=4380 RES=0x00 SYN URGP=0 > > Extending the rule to: > > DNAT net loc0:$XEN0:22 tcp 52022 - $DSL_IP > SSH(ACCEPT) net loc0:$XEN0 > > solves the problem. > > Guess it''s a bug. Or did I miss something?Hi Alex, Please post the output of ''shorewall show net2loc0'' (or net-loc0 if use use ZONE2ZONE="-") without the extra ACCEPT rule. My tests here show that the correct ACCEPT rule is getting created. Thanks, -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 \________________________________________________ ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2
On Wed, 2011-07-06 at 14:05 -0700, Tom Eastep wrote:> On Wed, 2011-07-06 at 22:20 +0200, Alexander Wilms wrote:> > SW:net2loc0:DROP:IN=eth1 OUT=eth0 SRC=85.182.238.98 DST=192.168.1.2 LEN=60 TOS=0x00 PREC=0x00 TTL=57 ID=36614 DF PROTO=TCP SPT=43415 DPT=22 WINDOW=4380 RES=0x00 SYN URGP=0> Please post the output of ''shorewall show net2loc0'' (or net-loc0 if > use use ZONE2ZONE="-") without the extra ACCEPT rule. My tests here > show that the correct ACCEPT rule is getting created.Duh -- the name ''net2loc0'' appears in the log message you posted... -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 \________________________________________________ ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2
Hi Tom,
here it comes:
horewall 4.4.20.3 Chain net2loc0 at fire - Mi 6. Jul 23:14:49 CEST 2011
Counters reset Mi 6. Jul 23:14:15 CEST 2011
Chain net2loc0 (1 references)
pkts bytes target prot opt in out source destination
260 61740 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
ctstate RELATED,ESTABLISHED
0 0 ACCEPT 89 -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
icmptype 8 /* Ping */
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.2
tcp dpt:22 ctorigdstport 14027 ctorigdst 62.143.214.30
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.2
tcp dpt:21 /* FTP */
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.1.100 tcp dpt:6881 /* BitTorrent */
0 0 ACCEPT udp -- * * 0.0.0.0/0
192.168.1.100 udp dpt:4444 /* BitTorrent */
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.1.100 tcp dpt:7403 /* BitTorrent */
0 0 ACCEPT udp -- * * 0.0.0.0/0
192.168.1.100 udp dpt:7403 /* BitTorrent */
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.3
multiport dports 3000,2004
5 300 Drop all -- * * 0.0.0.0/0 0.0.0.0/0
5 300 LOG all -- * * 0.0.0.0/0 0.0.0.0/0
LOG flags 0 level 6 prefix "SW:net2loc0:DROP:"
5 300 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
----- Ursprüngliche Mail -----
Von: "Tom Eastep" <teastep@shorewall.net>
An: "Shorewall Users" <shorewall-users@lists.sourceforge.net>
Gesendet: Mittwoch, 6. Juli 2011 23:05:03
Betreff: Re: [Shorewall-users] DNAT behaves like DNAT-
On Wed, 2011-07-06 at 22:20 +0200, Alexander Wilms wrote:
Hi Tom, hi list
I upgraded my firewall system which included an update to
shorewall-4.4.20.3-1.1.noarch (SuSE build service rpm).
After that, DNAT seems to behave like DNAT- if the DNAT is directed to another
DST port. Without port-translation it works as expected.
Using this rules is not enough
DNAT net loc0:$XEN0:22 tcp 52022 -
$DSL_IP
as this is logged:
SW:net2loc0:DROP:IN=eth1 OUT=eth0 SRC=85.182.238.98 DST=192.168.1.2 LEN=60
TOS=0x00 PREC=0x00 TTL=57 ID=36614 DF PROTO=TCP SPT=43415 DPT=22 WINDOW=4380
RES=0x00 SYN URGP=0
Extending the rule to:
DNAT net loc0:$XEN0:22 tcp 52022 -
$DSL_IP
SSH(ACCEPT) net loc0:$XEN0
solves the problem.
Guess it's a bug. Or did I miss something?
Hi Alex,
Please post the output of 'shorewall show net2loc0' (or net-loc0 if use
use ZONE2ZONE="-") without the extra ACCEPT rule. My tests here show
that the correct ACCEPT rule is getting created.
Thanks,
-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
\________________________________________________
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
And here with the explicit SSH rule:
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.2
tcp dpt:22 ctorigdstport 14027 ctorigdst 62.143.214.30
1 60 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.2
tcp dpt:22 /* SSH */
This "ctorigdstport 14027" shouldn't happen, isn't it?
----- Ursprüngliche Mail -----
Von: "Tom Eastep" <teastep@shorewall.net>
An: "Shorewall Users" <shorewall-users@lists.sourceforge.net>
Gesendet: Mittwoch, 6. Juli 2011 23:12:32
Betreff: Re: [Shorewall-users] DNAT behaves like DNAT-
On Wed, 2011-07-06 at 14:05 -0700, Tom Eastep wrote:
On Wed, 2011-07-06 at 22:20 +0200, Alexander Wilms wrote:
SW:net2loc0:DROP:IN=eth1 OUT=eth0 SRC=85.182.238.98 DST=192.168.1.2 LEN=60
TOS=0x00 PREC=0x00 TTL=57 ID=36614 DF PROTO=TCP SPT=43415 DPT=22 WINDOW=4380
RES=0x00 SYN URGP=0
Please post the output of 'shorewall show net2loc0' (or net-loc0 if use
use ZONE2ZONE="-") without the extra ACCEPT rule. My tests here show
that the correct ACCEPT rule is getting created.
Duh -- the name 'net2loc0' appears in the log message you posted...
-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
\________________________________________________
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
On Wed, 2011-07-06 at 23:16 +0200, Alexander Wilms wrote:> Hi Tom, > > here it comes: > > horewall 4.4.20.3 Chain net2loc0 at fire - Mi 6. Jul 23:14:49 CEST 2011 > > Counters reset Mi 6. Jul 23:14:15 CEST 2011 > > Chain net2loc0 (1 references) > pkts bytes target prot opt in out source destination > 260 61740 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED > 0 0 ACCEPT 89 -- * * 0.0.0.0/0 0.0.0.0/0 > 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8 /* Ping */ > 0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.2 tcp dpt:22 ctorigdstport 14027 ctorigdst 62.143.214.30Although the original destination port was 52022, iptables is interpreting it as 14027. I have the same problem where port 8080 is being interpreted as 36895. Looks like the iptables code is missing a call to hton() since 8080 = 0x1f90 and 36895 = 0x901f. In your case, 52022 = 0xcb36 while 15027 = 0x36cb. Which iptables version are you running? The bug appears in iptables 1.4.11 but is absent in iptables 1.4.8. Probably in Jan''s new guided option parser for ctstate. -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 \________________________________________________ ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2
My version is iptables-1.4.11+-21.1.i586
----- Ursprüngliche Mail -----
Von: "Tom Eastep" <teastep@shorewall.net>
An: "Shorewall Users" <shorewall-users@lists.sourceforge.net>
Gesendet: Mittwoch, 6. Juli 2011 23:40:09
Betreff: Re: [Shorewall-users] DNAT behaves like DNAT-
On Wed, 2011-07-06 at 23:16 +0200, Alexander Wilms wrote:
Hi Tom,
here it comes:
horewall 4.4.20.3 Chain net2loc0 at fire - Mi 6. Jul 23:14:49 CEST 2011
Counters reset Mi 6. Jul 23:14:15 CEST 2011
Chain net2loc0 (1 references)
pkts bytes target prot opt in out source destination
260 61740 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
ctstate RELATED,ESTABLISHED
0 0 ACCEPT 89 -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
icmptype 8 /* Ping */
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.2
tcp dpt:22 ctorigdstport 14027 ctorigdst 62.143.214.30
Although the original destination port was 52022, iptables is interpreting it as
14027. I have the same problem where port 8080 is being interpreted as 36895.
Looks like the iptables code is missing a call to hton() since 8080 = 0x1f90 and
36895 = 0x901f.
In your case, 52022 = 0xcb36 while 15027 = 0x36cb.
Which iptables version are you running? The bug appears in iptables 1.4.11 but
is absent in iptables 1.4.8. Probably in Jan's new guided option parser for
ctstate.
-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
\________________________________________________
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
On Wed, 2011-07-06 at 23:46 +0200, Alexander Wilms wrote:> My version is iptables-1.4.11+-21.1.i586That''s where the bug is. -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 \________________________________________________ ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2
Ack, downgraded to plain openSUSE iptables-1.4.10-3.1.i586.rpm, result is now a correct "ctorigdstport 52022" 1 60 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.2 tcp dpt:22 ctorigdstport 52022 ctorigdst 62.143.214.30 My mistake was having the http://download.opensuse.org/repositories/security:/netfilter/openSUSE_11.4/ repository enabled (for shorewall :-) ) As you knew the bug: Is there already a bug report in the netfilter list? ----- Ursprüngliche Mail ----- Von: "Tom Eastep" <teastep@shorewall.net> An: "Shorewall Users" <shorewall-users@lists.sourceforge.net> Gesendet: Mittwoch, 6. Juli 2011 23:53:00 Betreff: Re: [Shorewall-users] DNAT behaves like DNAT- On Wed, 2011-07-06 at 23:46 +0200, Alexander Wilms wrote: My version is iptables-1.4.11+-21.1.i586 That's where the bug is. -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 \________________________________________________ ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
On Wed, 2011-07-06 at 14:53 -0700, Tom Eastep wrote:> On Wed, 2011-07-06 at 23:46 +0200, Alexander Wilms wrote: > > > My version is iptables-1.4.11+-21.1.i586 > > > That''s where the bug is. > > -Here is a patch to libxt_conntrack.c if you happen to be in a position to build your own iptables. -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 \________________________________________________ ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2
No need to patch myself, can live with older iptables. Goal of my question was just to ask if it would be useful to open a bug report. But I guess a bug report exists already as a patch is available. Anyway, thank you for your great support, Tom, ...as always :-) ----- Ursprüngliche Mail ----- Von: "Tom Eastep" <teastep@shorewall.net> An: "Shorewall Users" <shorewall-users@lists.sourceforge.net> Gesendet: Donnerstag, 7. Juli 2011 00:05:32 Betreff: Re: [Shorewall-users] DNAT behaves like DNAT- On Wed, 2011-07-06 at 14:53 -0700, Tom Eastep wrote: On Wed, 2011-07-06 at 23:46 +0200, Alexander Wilms wrote: My version is iptables-1.4.11+-21.1.i586 That's where the bug is. - Here is a patch to libxt_conntrack.c if you happen to be in a position to build your own iptables. -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 \________________________________________________ ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
I just wrote that patch and it really isn''t the correct one. The attached one is better and I''ll submit it to the netfilter team since the online git repository shows the original code. Cheers, Alex -Tom On Thu, 2011-07-07 at 00:15 +0200, Alexander Wilms wrote:> No need to patch myself, can live with older iptables. > > Goal of my question was just to ask if it would be useful to open a bug report. > But I guess a bug report exists already as a patch is available. > > Anyway, thank you for your great support, Tom, > > ...as always :-) > > ----- Ursprüngliche Mail ----- > Von: "Tom Eastep" <teastep@shorewall.net> > An: "Shorewall Users" <shorewall-users@lists.sourceforge.net> > Gesendet: Donnerstag, 7. Juli 2011 00:05:32 > Betreff: Re: [Shorewall-users] DNAT behaves like DNAT- > > > On Wed, 2011-07-06 at 14:53 -0700, Tom Eastep wrote: > > > On Wed, 2011-07-06 at 23:46 +0200, Alexander Wilms wrote: > > My version is iptables-1.4.11+-21.1.i586 > That''s where the bug is. > > - > Here is a patch to libxt_conntrack.c if you happen to be in a position to build your own iptables. > > -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 \________________________________________________ > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users-- 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 \________________________________________________ ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2
On 6 Jul 2011, at 22:59, Alexander Wilms wrote:> Ack, downgraded to plain openSUSE iptables-1.4.10-3.1.i586.rpm, result is now a correct "ctorigdstport 52022" > > 1 60 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.2 tcp dpt:22 ctorigdstport 52022 ctorigdst 62.143.214.30 > > My mistake was having the http://download.opensuse.org/repositories/security:/netfilter/openSUSE_11.4/ repository enabled (for shorewall :-) ) > > > As you knew the bug: Is there already a bug report in the netfilter list?I think this is already fixed in 1.4.11.1, and there''s a corresponding patch in Debian sid (1.4.11-3). ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2
On Jul 6, 2011, at 3:26 PM, Dominic Benson wrote:> > On 6 Jul 2011, at 22:59, Alexander Wilms wrote: > >> Ack, downgraded to plain openSUSE iptables-1.4.10-3.1.i586.rpm, result is now a correct "ctorigdstport 52022" >> >> 1 60 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.2 tcp dpt:22 ctorigdstport 52022 ctorigdst 62.143.214.30 >> >> My mistake was having the http://download.opensuse.org/repositories/security:/netfilter/openSUSE_11.4/ repository enabled (for shorewall :-) ) >> >> >> As you knew the bug: Is there already a bug report in the netfilter list? > > > I think this is already fixed in 1.4.11.1, and there''s a corresponding patch in Debian sid (1.4.11-3). >I''m running 1.4.11.1 and it isn''t fixed there. I just cloned the iptables git repository and don''t see that it is corrected there either. -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 \________________________________________________ ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2
On 7 Jul 2011, at 00:09, Tom Eastep wrote:> > On Jul 6, 2011, at 3:26 PM, Dominic Benson wrote: > >> >> On 6 Jul 2011, at 22:59, Alexander Wilms wrote: >> >>> Ack, downgraded to plain openSUSE iptables-1.4.10-3.1.i586.rpm, result is now a correct "ctorigdstport 52022" >>> >>> 1 60 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.2 tcp dpt:22 ctorigdstport 52022 ctorigdst 62.143.214.30 >>> >>> My mistake was having the http://download.opensuse.org/repositories/security:/netfilter/openSUSE_11.4/ repository enabled (for shorewall :-) ) >>> >>> >>> As you knew the bug: Is there already a bug report in the netfilter list? >> >> >> I think this is already fixed in 1.4.11.1, and there''s a corresponding patch in Debian sid (1.4.11-3). >> > > I''m running 1.4.11.1 and it isn''t fixed there. I just cloned the iptables git repository and don''t see that it is corrected there either. > > -TomSorry, you''re absolutely right. I just realised the test I did would have matched an ACCEPT anyway. ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2
On Jul 6, 2011, at 4:17 PM, Dominic Benson wrote:> > On 7 Jul 2011, at 00:09, Tom Eastep wrote: > >> >> On Jul 6, 2011, at 3:26 PM, Dominic Benson wrote: >> >>> >>> On 6 Jul 2011, at 22:59, Alexander Wilms wrote: >>> >>>> Ack, downgraded to plain openSUSE iptables-1.4.10-3.1.i586.rpm, result is now a correct "ctorigdstport 52022" >>>> >>>> 1 60 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.2 tcp dpt:22 ctorigdstport 52022 ctorigdst 62.143.214.30 >>>> >>>> My mistake was having the http://download.opensuse.org/repositories/security:/netfilter/openSUSE_11.4/ repository enabled (for shorewall :-) ) >>>> >>>> >>>> As you knew the bug: Is there already a bug report in the netfilter list? >>> >>> >>> I think this is already fixed in 1.4.11.1, and there''s a corresponding patch in Debian sid (1.4.11-3). >>> >> >> I''m running 1.4.11.1 and it isn''t fixed there. I just cloned the iptables git repository and don''t see that it is corrected there either. >> >> -Tom > > Sorry, you''re absolutely right. I just realised the test I did would have matched an ACCEPT anyway.No problem. I''ve reported the problem on netfilter-devel. -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 \________________________________________________ ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2
According to http://www.netfilter.org/projects/iptables/files/changes-iptables-1.4.11.1.txt and the corresponding patch not. ----- Ursprüngliche Mail ----- Von: "Dominic Benson" <dominic@lenny.cus.org> An: "Shorewall Users" <shorewall-users@lists.sourceforge.net> Gesendet: Donnerstag, 7. Juli 2011 00:26:12 Betreff: Re: [Shorewall-users] DNAT behaves like DNAT- I think this is already fixed in 1.4.11.1, and there's a corresponding patch in Debian sid (1.4.11-3). ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
On Jul 6, 2011, at 4:23 PM, Tom Eastep wrote:> > No problem. I''ve reported the problem on netfilter-devel. >The netfilter developers have accepted my (second) patch. -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 \________________________________________________ ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2