I''ve found a couple of more issues with 4.5.13 Beta 2. 1) An internal error can be raised while trying to complete a built-in chain like INPUT. 2) Audited RELATED_DISPOSITION (e.g., RELATED_DISPOSITION=A_ACCEPT) is effectively ignored. Patches attached. -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 \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412
On 01/21/2013 09:08 AM, Tom Eastep wrote:> I''ve found a couple of more issues with 4.5.13 Beta 2. > > 1) An internal error can be raised while trying to complete a built-in > chain like INPUT. > > 2) Audited RELATED_DISPOSITION (e.g., RELATED_DISPOSITION=A_ACCEPT) is > effectively ignored. > > Patches attached.Here''s a fix on top of the second patch above; it avoids perl diagnostics when RELATED_DISPOSITION is ''REJECT''. -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 \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412
There is another (quite annoying) issue I''ve discovered with 4.5.12 (maybe valid with 4.5.13 betas, don''t know), which I think requires a little attention: shorewall.conf ~~~~~~~~~~~~~~ RELATED_DISPOSITION=ACCEPT blrules ~~~~~~~ WHITELIST fw net:+whitelist <EOF> rules ~~~~~ SECTION RELATED IFLOG(accept,log,nflog1,2,mamas,DROP) $FW net SECTION NEW dropInvalid all all [...] generates these rules: -A fw2net -m conntrack --ctstate NEW,INVALID -m set --match-set whitelist dst -j RETURN -A fw2net -m conntrack --ctstate ESTABLISHED -j ACCEPT -A fw2net -m conntrack --ctstate RELATED -j +fw2net -A fw2net -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT -A fw2net -m conntrack --ctstate INVALID -j DROP 1st rule above: even though it is the only one which exists in "blrules" for this chain (fw2net), it should not have been optimised in this way (RETURN from fw2net will prevent further traversing!). Also, why is --cstate INVALID included in that match (I do have BLACKLISTNEWONLY=Yes, but that doesn''t explain the INVALID match being there)? The correct rule should have been a single "--cstate INVALID -j DROP", if anything (as shown in the last rule listed there). 2nd-to-last rule: where did that come from? I have similar rules generated for all of my other chains (net2fw, local2fw, fw2local ...). I am sorry I couldn''t participate in the testing of the previous betas, but I have been quite busy and it looks as though that would be the way at least until the end of Jan. Tom Eastep wrote:> On 01/21/2013 09:08 AM, Tom Eastep wrote: > >> I''ve found a couple of more issues with 4.5.13 Beta 2. >> >> 1) An internal error can be raised while trying to complete a built-in >> chain like INPUT. >> >> 2) Audited RELATED_DISPOSITION (e.g., RELATED_DISPOSITION=A_ACCEPT) is >> effectively ignored. >> >> Patches attached. >> > > Here''s a fix on top of the second patch above; it avoids perl > diagnostics when RELATED_DISPOSITION is ''REJECT''. > > -Tom > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. SALE $99.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122412 > ------------------------------------------------------------------------ > > _______________________________________________ > Shorewall-devel mailing list > Shorewall-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-devel >------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
On 01/22/2013 05:04 AM, Mr Dash Four wrote:> There is another (quite annoying) issue I''ve discovered with 4.5.12 > (maybe valid with 4.5.13 betas, don''t know), which I think requires a > little attention: > > shorewall.conf > ~~~~~~~~~~~~~~ > RELATED_DISPOSITION=ACCEPT > > blrules > ~~~~~~~ > WHITELIST fw net:+whitelist > <EOF> > > rules > ~~~~~ > SECTION RELATED > IFLOG(accept,log,nflog1,2,mamas,DROP) $FW net > SECTION NEW > dropInvalid all all > [...] > > generates these rules: > > -A fw2net -m conntrack --ctstate NEW,INVALID -m set --match-set > whitelist dst -j RETURN > -A fw2net -m conntrack --ctstate ESTABLISHED -j ACCEPT > -A fw2net -m conntrack --ctstate RELATED -j +fw2net > -A fw2net -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT > -A fw2net -m conntrack --ctstate INVALID -j DROP > > 1st rule above: even though it is the only one which exists in "blrules" > for this chain (fw2net), it should not have been optimised in this way > (RETURN from fw2net will prevent further traversing!).Yes -- that''s a bug. Patch attached.> > Also, why is --cstate INVALID included in that match (I do have > BLACKLISTNEWONLY=Yes, but that doesn''t explain the INVALID match being > there)?The rationale there is that sending packets in an invalid state should not allow someone to bypass the blacklist rules. So I would prefer to change the description of the BLACKLISTNEWONLY option rather than the code.> The correct rule should have been a single "--cstate INVALID -j > DROP", if anything (as shown in the last rule listed there). > > 2nd-to-last rule: where did that come from? I have similar rules > generated for all of my other chains (net2fw, local2fw, fw2local ...).Yes -- with RELATED_DISPOSITION=ACCEPT, simply accepting packets in ESTABLISHED state would be enough. That is a left-over from before I implemented RELATED_DISPOSITION. I''ll clean that up in this release.> > I am sorry I couldn''t participate in the testing of the previous betas, > but I have been quite busy and it looks as though that would be the way > at least until the end of Jan.I would anticipate RC 1 being available about that time so hopefully you can test then. 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 \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
> Yes -- that''s a bug. Patch attached. >I might be able to give it a quick whirl tomorrow (it would be just for that single fix). If so, will let you know.>> Also, why is --cstate INVALID included in that match (I do have >> BLACKLISTNEWONLY=Yes, but that doesn''t explain the INVALID match being >> there)? >> > > The rationale there is that sending packets in an invalid state should > not allow someone to bypass the blacklist rules. So I would prefer to > change the description of the BLACKLISTNEWONLY option rather than the code. >More reason to implement my (previous) idea of introducing INVALID_DISPOSITION and treat it completely different from anything else. If we had that (say INVALID_DISPOSITION=A_DROP) then there will be two distinct (and very clear) rules in that chain and I won''t be scratching my head wondering what the hell is going on (and I won''t have to modify the core chains/use dropInvalid either).> Yes -- with RELATED_DISPOSITION=ACCEPT, simply accepting packets in > ESTABLISHED state would be enough. That is a left-over from before I > implemented RELATED_DISPOSITION. I''ll clean that up in this release. >OK, thanks.> I would anticipate RC 1 being available about that time so hopefully you > can test then. >Yep, I am also hoping I will have more time to test this. ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
On 01/22/2013 08:13 AM, Tom Eastep wrote:> On 01/22/2013 05:04 AM, Mr Dash Four wrote: >> There is another (quite annoying) issue I''ve discovered with 4.5.12 >> (maybe valid with 4.5.13 betas, don''t know), which I think requires a >> little attention: >> >> shorewall.conf >> ~~~~~~~~~~~~~~ >> RELATED_DISPOSITION=ACCEPT >> >> blrules >> ~~~~~~~ >> WHITELIST fw net:+whitelist >> <EOF> >> >> rules >> ~~~~~ >> SECTION RELATED >> IFLOG(accept,log,nflog1,2,mamas,DROP) $FW net >> SECTION NEW >> dropInvalid all all >> [...] >> >> generates these rules: >> >> -A fw2net -m conntrack --ctstate NEW,INVALID -m set --match-set >> whitelist dst -j RETURN >> -A fw2net -m conntrack --ctstate ESTABLISHED -j ACCEPT >> -A fw2net -m conntrack --ctstate RELATED -j +fw2net >> -A fw2net -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT >> -A fw2net -m conntrack --ctstate INVALID -j DROP >> >> 1st rule above: even though it is the only one which exists in "blrules" >> for this chain (fw2net), it should not have been optimised in this way >> (RETURN from fw2net will prevent further traversing!). > > Yes -- that''s a bug. Patch attached. > >> >> Also, why is --cstate INVALID included in that match (I do have >> BLACKLISTNEWONLY=Yes, but that doesn''t explain the INVALID match being >> there)? > > The rationale there is that sending packets in an invalid state should > not allow someone to bypass the blacklist rules. So I would prefer to > change the description of the BLACKLISTNEWONLY option rather than the code. > >> The correct rule should have been a single "--cstate INVALID -j >> DROP", if anything (as shown in the last rule listed there). >> >> 2nd-to-last rule: where did that come from? I have similar rules >> generated for all of my other chains (net2fw, local2fw, fw2local ...). > > Yes -- with RELATED_DISPOSITION=ACCEPT, simply accepting packets in > ESTABLISHED state would be enough. That is a left-over from before I > implemented RELATED_DISPOSITION. I''ll clean that up in this release.I just took another look at this and I''m not clear where that is coming from in your case. From my own ruleset: -A net-fw -m conntrack --ctstate NEW,INVALID -j net-fw~ -A net-fw -i eth0 -j eth0_iop -A net-fw -i eth1 -j eth1_iop -A net-fw -m conntrack --ctstate ESTABLISHED -j ACCEPT -A net-fw -m conntrack --ctstate RELATED -j +net-fw -A net-fw -p tcp --syn -j @net-all -A net-fw -p udp --dport 1194 -j ACCEPT ... -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 \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
On 01/22/2013 10:36 AM, Tom Eastep wrote:> On 01/22/2013 08:13 AM, Tom Eastep wrote: >> On 01/22/2013 05:04 AM, Mr Dash Four wrote: >>> There is another (quite annoying) issue I''ve discovered with 4.5.12 >>> (maybe valid with 4.5.13 betas, don''t know), which I think requires a >>> little attention: >>> >>> shorewall.conf >>> ~~~~~~~~~~~~~~ >>> RELATED_DISPOSITION=ACCEPT >>> >>> blrules >>> ~~~~~~~ >>> WHITELIST fw net:+whitelist >>> <EOF> >>> >>> rules >>> ~~~~~ >>> SECTION RELATED >>> IFLOG(accept,log,nflog1,2,mamas,DROP) $FW net >>> SECTION NEW >>> dropInvalid all all >>> [...] >>> >>> generates these rules: >>> >>> -A fw2net -m conntrack --ctstate NEW,INVALID -m set --match-set >>> whitelist dst -j RETURN >>> -A fw2net -m conntrack --ctstate ESTABLISHED -j ACCEPT >>> -A fw2net -m conntrack --ctstate RELATED -j +fw2net >>> -A fw2net -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT >>> -A fw2net -m conntrack --ctstate INVALID -j DROP >>> >>> 1st rule above: even though it is the only one which exists in "blrules" >>> for this chain (fw2net), it should not have been optimised in this way >>> (RETURN from fw2net will prevent further traversing!). >> >> Yes -- that''s a bug. Patch attached. >> >>> >>> Also, why is --cstate INVALID included in that match (I do have >>> BLACKLISTNEWONLY=Yes, but that doesn''t explain the INVALID match being >>> there)? >> >> The rationale there is that sending packets in an invalid state should >> not allow someone to bypass the blacklist rules. So I would prefer to >> change the description of the BLACKLISTNEWONLY option rather than the code. >> >>> The correct rule should have been a single "--cstate INVALID -j >>> DROP", if anything (as shown in the last rule listed there). >>> >>> 2nd-to-last rule: where did that come from? I have similar rules >>> generated for all of my other chains (net2fw, local2fw, fw2local ...). >> >> Yes -- with RELATED_DISPOSITION=ACCEPT, simply accepting packets in >> ESTABLISHED state would be enough. That is a left-over from before I >> implemented RELATED_DISPOSITION. I''ll clean that up in this release. > > I just took another look at this and I''m not clear where that is coming > from in your case. From my own ruleset: > > -A net-fw -m conntrack --ctstate NEW,INVALID -j net-fw~ > -A net-fw -i eth0 -j eth0_iop > -A net-fw -i eth1 -j eth1_iop > -A net-fw -m conntrack --ctstate ESTABLISHED -j ACCEPT > -A net-fw -m conntrack --ctstate RELATED -j +net-fw > -A net-fw -p tcp --syn -j @net-all > -A net-fw -p udp --dport 1194 -j ACCEPT > ...I''ve reproduced the problem and will include a fix in the next Beta. -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 \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
On 01/22/2013 11:16 AM, Tom Eastep wrote:> On 01/22/2013 10:36 AM, Tom Eastep wrote: >> On 01/22/2013 08:13 AM, Tom Eastep wrote: >>> On 01/22/2013 05:04 AM, Mr Dash Four wrote:>>>> -A fw2net -m conntrack --ctstate NEW,INVALID -m set --match-set >>>> whitelist dst -j RETURN >>>> -A fw2net -m conntrack --ctstate ESTABLISHED -j ACCEPT >>>> -A fw2net -m conntrack --ctstate RELATED -j +fw2net >>>> -A fw2net -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT >>>> -A fw2net -m conntrack --ctstate INVALID -j DROP>>>> 2nd-to-last rule: where did that come from? I have similar rules >>>> generated for all of my other chains (net2fw, local2fw, fw2local ...). >>> >>> Yes -- with RELATED_DISPOSITION=ACCEPT, simply accepting packets in >>> ESTABLISHED state would be enough. That is a left-over from before I >>> implemented RELATED_DISPOSITION. I''ll clean that up in this release. >> >> I just took another look at this and I''m not clear where that is coming >> from in your case. From my own ruleset: >> >> -A net-fw -m conntrack --ctstate NEW,INVALID -j net-fw~ >> -A net-fw -i eth0 -j eth0_iop >> -A net-fw -i eth1 -j eth1_iop >> -A net-fw -m conntrack --ctstate ESTABLISHED -j ACCEPT >> -A net-fw -m conntrack --ctstate RELATED -j +net-fw >> -A net-fw -p tcp --syn -j @net-all >> -A net-fw -p udp --dport 1194 -j ACCEPT >> ... > > I''ve reproduced the problem and will include a fix in the next Beta.Patch attached. -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 \________________________________________________ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
On 1/22/13 3:12 PM, "Tom Eastep" <teastep@shorewall.net> wrote:>On 01/22/2013 11:16 AM, Tom Eastep wrote: >> On 01/22/2013 10:36 AM, Tom Eastep wrote: >>> On 01/22/2013 08:13 AM, Tom Eastep wrote: >>>> On 01/22/2013 05:04 AM, Mr Dash Four wrote: > >>>>> -A fw2net -m conntrack --ctstate NEW,INVALID -m set --match-set >>>>> whitelist dst -j RETURN >>>>> -A fw2net -m conntrack --ctstate ESTABLISHED -j ACCEPT >>>>> -A fw2net -m conntrack --ctstate RELATED -j +fw2net >>>>> -A fw2net -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT >>>>> -A fw2net -m conntrack --ctstate INVALID -j DROP > >>>>> 2nd-to-last rule: where did that come from? I have similar rules >>>>> generated for all of my other chains (net2fw, local2fw, fw2local >>>>>...). >>>> >>>> Yes -- with RELATED_DISPOSITION=ACCEPT, simply accepting packets in >>>> ESTABLISHED state would be enough. That is a left-over from before I >>>> implemented RELATED_DISPOSITION. I''ll clean that up in this release. >>> >>> I just took another look at this and I''m not clear where that is coming >>> from in your case. From my own ruleset: >>> >>> -A net-fw -m conntrack --ctstate NEW,INVALID -j net-fw~ >>> -A net-fw -i eth0 -j eth0_iop >>> -A net-fw -i eth1 -j eth1_iop >>> -A net-fw -m conntrack --ctstate ESTABLISHED -j ACCEPT >>> -A net-fw -m conntrack --ctstate RELATED -j +net-fw >>> -A net-fw -p tcp --syn -j @net-all >>> -A net-fw -p udp --dport 1194 -j ACCEPT >>> ... >> >> I''ve reproduced the problem and will include a fix in the next Beta. > >Patch attached.Bad patch -- here''s the replacement. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
Tom Eastep wrote:> On 1/22/13 3:12 PM, "Tom Eastep" <teastep@shorewall.net> wrote: > >> On 01/22/2013 11:16 AM, Tom Eastep wrote: >>> On 01/22/2013 10:36 AM, Tom Eastep wrote: >>>> On 01/22/2013 08:13 AM, Tom Eastep wrote: >>>>> On 01/22/2013 05:04 AM, Mr Dash Four wrote: >>>>>> -A fw2net -m conntrack --ctstate NEW,INVALID -m set --match-set >>>>>> whitelist dst -j RETURN >>>>>> -A fw2net -m conntrack --ctstate ESTABLISHED -j ACCEPT >>>>>> -A fw2net -m conntrack --ctstate RELATED -j +fw2net >>>>>> -A fw2net -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT >>>>>> -A fw2net -m conntrack --ctstate INVALID -j DROP >>>>>> 2nd-to-last rule: where did that come from? I have similar rules >>>>>> generated for all of my other chains (net2fw, local2fw, fw2local >>>>>> ...). >>>>> Yes -- with RELATED_DISPOSITION=ACCEPT, simply accepting packets in >>>>> ESTABLISHED state would be enough. That is a left-over from before I >>>>> implemented RELATED_DISPOSITION. I''ll clean that up in this release. >>>> I just took another look at this and I''m not clear where that is coming >>>> from in your case. From my own ruleset: >>>> >>>> -A net-fw -m conntrack --ctstate NEW,INVALID -j net-fw~ >>>> -A net-fw -i eth0 -j eth0_iop >>>> -A net-fw -i eth1 -j eth1_iop >>>> -A net-fw -m conntrack --ctstate ESTABLISHED -j ACCEPT >>>> -A net-fw -m conntrack --ctstate RELATED -j +net-fw >>>> -A net-fw -p tcp --syn -j @net-all >>>> -A net-fw -p udp --dport 1194 -j ACCEPT >>>> ... >>> I''ve reproduced the problem and will include a fix in the next Beta. >> Patch attached. > > Bad patch -- here''s the replacement.I assume this patch was for the 2nd-to-last rule (which is now gone, though I had to alter the patch a bit as the 2nd hunk was failing) and not for the erroneous RETURN from fw2net, is that correct? ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
On 1/23/13 3:55 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> > >Tom Eastep wrote: >> On 1/22/13 3:12 PM, "Tom Eastep" <teastep@shorewall.net> wrote: >> >>> On 01/22/2013 11:16 AM, Tom Eastep wrote: >>>> On 01/22/2013 10:36 AM, Tom Eastep wrote: >>>>> On 01/22/2013 08:13 AM, Tom Eastep wrote: >>>>>> On 01/22/2013 05:04 AM, Mr Dash Four wrote: >>>>>>> -A fw2net -m conntrack --ctstate NEW,INVALID -m set --match-set >>>>>>> whitelist dst -j RETURN >>>>>>> -A fw2net -m conntrack --ctstate ESTABLISHED -j ACCEPT >>>>>>> -A fw2net -m conntrack --ctstate RELATED -j +fw2net >>>>>>> -A fw2net -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT >>>>>>> -A fw2net -m conntrack --ctstate INVALID -j DROP >>>>>>> 2nd-to-last rule: where did that come from? I have similar rules >>>>>>> generated for all of my other chains (net2fw, local2fw, fw2local >>>>>>> ...). >>>>>> Yes -- with RELATED_DISPOSITION=ACCEPT, simply accepting packets in >>>>>> ESTABLISHED state would be enough. That is a left-over from before I >>>>>> implemented RELATED_DISPOSITION. I''ll clean that up in this >>>>>>release. >>>>> I just took another look at this and I''m not clear where that is >>>>>coming >>>>> from in your case. From my own ruleset: >>>>> >>>>> -A net-fw -m conntrack --ctstate NEW,INVALID -j net-fw~ >>>>> -A net-fw -i eth0 -j eth0_iop >>>>> -A net-fw -i eth1 -j eth1_iop >>>>> -A net-fw -m conntrack --ctstate ESTABLISHED -j ACCEPT >>>>> -A net-fw -m conntrack --ctstate RELATED -j +net-fw >>>>> -A net-fw -p tcp --syn -j @net-all >>>>> -A net-fw -p udp --dport 1194 -j ACCEPT >>>>> ... >>>> I''ve reproduced the problem and will include a fix in the next Beta. >>> Patch attached. >> >> Bad patch -- here''s the replacement. >I assume this patch was for the 2nd-to-last rule (which is now gone, >though I had to alter the patch a bit as the 2nd hunk was failing) and >not for the erroneous RETURN from fw2net, is that correct?That''s correct. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
> That''s correct.It does its job then as this statement is now gone. ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
On 1/23/13 4:47 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:>> That''s correct. >It does its job then as this statement is now gone.Thanks, -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d