On 04/06/13 15:46, Tom Eastep wrote:
> On 06/04/2013 07:26 AM, Brian Burch wrote:
>
>> I did not have anything similar in the rules file, so I added the
>> all/all variant as the first entry on my natting firewall.
>>
>> After this change, the martians are no longer appearing at my outside
>> firewall, even when the client systems have resumed after a long idle
>> time, so I conclude that your suggestion has resolved my problem.
>>
>> The inner firewall is running shorewall 4.4, so I couldn't help
>> wondering whether your rule would work... the docs imply that Invalid
>> (which isn't a macro) was introduced with version 4.5. However, it does
>> seem to work, although I don't have templates for variables such as
>> INVALID_DISPOSITION and INVALID_LOG_LEVEL in the shorewall.conf file.
>
> Those options were added when the INVALID section of the rules file was
> created.
>
>>
>> Forgive me being a bit lazy, but does "invalid" mean simply "not in the
>> conntrack cache", or does it have a wider definition that I ought to be
>> cautious about?
>
> Invalid means that there is not a matching conntrack entry and one
> should not be created from that particular packet. In your case, a
> FIN/ACK should not be the first packet seen as part of a connection;
> that should rather be a SYN packet (with no ACK).

Thanks for explaining. Now my wireshark traces make perfect sense. As 
the FIN/ACK retry intervals extend to several seconds for a particular 
client source port, I see new SYN 3-way connection initiation on a new 
client port to the same external web server - just the right trigger to 
create a new conntrack entry. Of course, there isn't a linear 
progression because there are several asynchronous parallel connections. 
If I had a sufficiently comprehensive trace and made the effort to 
decrypt all the ssl streams, I expect I would be able to correlate each 
expiring FIN/ACK sequence with a new connection carrying the same class 
of payload.

I am satisfied that I have killed my martians without causing any 
collateral damage! I hope this conversation will be helpful to others 
who notice similar log messages.

Brian

>
> -Tom
>
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
>
>
>
> _______________________________________________
> Shorewall-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
>


------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to