Re: [Shorewall-users] providers->track option question

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Tom Eastep wrote:
> On 04/27/2013 01:26 PM, Dash Four wrote:
>   
>> On one of my dmz machines I need to define a separate provider, which 
>> holds a set of routes to/from the (public) internet, as well as 3 of my 
>> internal networks (all arriving or originating on the same interface).
>>
>> As I have TC_EXPERT=No, as well as TRACK_PROVIDERS=No and 
>> USE_DEFAULT_RT=No, what would be the appropriate option to use for this 
>> provider: "track", "notrack", or neither? The man page doesn't tell me 
>> much (either that, or I am getting a bit goofy today), so I need to 
>> canvass an opinion. Thanks.
>>     
>
> The 'track' option affects connection marking when incoming packets are
> received. When a packet is received on a 'track' provider and the packet
> either creates a new connection or is part of a connection with no
> connection mark, then the connection is marked with the provider's mark
> value. This causes all subsequent packets for that connection (in and
> out) to bypass the PREROUTING mangle rules (since you have TC_EXPERT=No)
> and simply use the connection mark's value for routing (in the absence
> of a relevant routing rule). In general, 'track' is the safe and
> efficient choice for a provider that has a configured mark value.
>   
Right, thanks Tom. If I use this provider for connections which do have 
a nat (from the top of my head, I do have at least 3 types of 
connections which get MASQUERADEd), should I then use the 'track' or 
not, given that all these connections have statements in rtrules to 
direct to my provider table, based on their final destinations. To give 
you a brief example of this:

in eth1->masquerade->eth0 out (the "provider" interface). My rtrules are 
with priorities 26000+ and are based on the destinations (subnet 
addresses) of these masqueraded connections. In addition, the dmz host 
(which has both eth0 and eth1 interfaces on it) also initiates such 
connections, but they start directly on the eth0 interface.