conntrackd and CacheWriteThrough

conntrackd and CacheWriteThrough

[Marco d'Itri]

When I try to start conntrackd (0.9.6 and 0.9.7, from the Debian
packages), it dies with this message:

Error parsing config file: line (58), symbol 'CacheWriteThrough': syntax error

What's wrong?

I have a pair of firewalls running quagga and OSPF announcing the
network behind them to my network core and keepalived managing a
virtual gateway on it, so I need an active-active setup because
traffic can enter the protected network from any of the firewalls.

This is my configuration file:

#
# Synchronizer settings
#
Sync {
        Mode FTFW {
                #
                # Size of the buffer that hold destroy messages for 
                # possible resends (in bytes)
                #
                ResendBufferSize 262144

                #
                # Entries committed to the connection tracking table 
                # starts with a limited timeout of N seconds until the
                # takeover process is completed.
                #
                CommitTimeout 180

                # Set Acknowledgement window size
                ACKWindowSize 20
        }

        #
        # Multicast IP and interface where messages are
        # broadcasted (dedicated link). IMPORTANT: Make sure
        # that iptables accepts traffic for destination
        # 225.0.0.50, eg:
        #
        #       iptables -I INPUT -d 225.0.0.50 -j ACCEPT
        #       iptables -I OUTPUT -d 225.0.0.50 -j ACCEPT
        #
        Multicast {
                IPv4_address 225.0.0.50
                IPv4_interface 85.94.204.77 # IP of dedicated link
                Interface eth2
                Group 3780
        }

        # Enable/Disable message checksumming
        Checksum on

        # Uncomment this if you want to replicate just certain TCP states.
        # This option introduces a tradeoff in the replication: it reduces
        # CPU consumption and lost messages rate at the cost of having 
        # backup replicas that don't contain the current state that the active 
        # replica holds. TCP states are: SYN_SENT, SYN_RECV, ESTABLISHED,
        # FIN_WAIT, CLOSE_WAIT, LAST_ACK, TIME_WAIT, CLOSE, LISTEN.
        # 
        # Replicate ESTABLISHED TIME_WAIT for TCP
        Replicate ESTABLISHED TIME_WAIT

        # If you have a multiprimary setup (active-active) without connection
        # persistency, ie. you can't know which firewall handles a packet
        # that is part of a connection, then you need direct commit of
        # conntrack entries to the kernel conntrack table. OSPF setups must
        # set on this option. Default is Off.
        #
        CacheWriteThrough On
}

[...]

-- 
ciao,
Marco

Re: conntrackd and CacheWriteThrough

[Pablo Neira Ayuso]

Marco d'Itri wrote:
> When I try to start conntrackd (0.9.6 and 0.9.7, from the Debian
> packages), it dies with this message:
> 
> Error parsing config file: line (58), symbol 'CacheWriteThrough': syntax error
> 
> What's wrong?
> 
> I have a pair of firewalls running quagga and OSPF announcing the
> network behind them to my network core and keepalived managing a
> virtual gateway on it, so I need an active-active setup because
> traffic can enter the protected network from any of the firewalls.

Sorry, this setup is no longer supported. At least until we find a sane
way to do it. See http://conntrack-tools.netfilter.org/manual.html.
Also see: http://marc.info/?l=netfilter&m=122164806109759&w=2

Anyway, about your problem:

> This is my configuration file:
[...]
> 
>         # Replicate ESTABLISHED TIME_WAIT for TCP
>         Replicate ESTABLISHED TIME_WAIT

Missing "for TCP" confuses the parsing?

>         # If you have a multiprimary setup (active-active) without connection
>         # persistency, ie. you can't know which firewall handles a packet
>         # that is part of a connection, then you need direct commit of
>         # conntrack entries to the kernel conntrack table. OSPF setups must
>         # set on this option. Default is Off.
>         #
>         CacheWriteThrough On
> }

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers

Re: conntrackd and CacheWriteThrough

[Marco d'Itri]

On Nov 04, Pablo Neira Ayuso <pablo@netfilter.org> wrote:

> Sorry, this setup is no longer supported. At least until we find a sane
> way to do it. See http://conntrack-tools.netfilter.org/manual.html.
> Also see: http://marc.info/?l=netfilter&m=122164806109759&w=2
Indeed I wondered about races between the traffic and state updates.

Load sharing with a multicast MAC address and sources hashing would not
help me because each one of my firewalls is connected to two core
routers with no shared L2 domain between them (i.e. each router is
connected to both firewalls).

My real goal is not sharing load but supporting asymmetrical routing,
because the firewalls announce the customer network to the core using
an IGP. If I am not missing anything I could use OSPF and give a lower
cost to the port with the higher VRRP priority.
This way I would be able to use normal active/passive conntrack
replication.

-- 
ciao,
Marco

Re: conntrackd and CacheWriteThrough

[Pablo Neira Ayuso]

Marco d'Itri wrote:
> On Nov 04, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> 
>> Sorry, this setup is no longer supported. At least until we find a sane
>> way to do it. See http://conntrack-tools.netfilter.org/manual.html.
>> Also see: http://marc.info/?l=netfilter&m=122164806109759&w=2
> Indeed I wondered about races between the traffic and state updates.
> 
> Load sharing with a multicast MAC address and sources hashing would not
> help me because each one of my firewalls is connected to two core
> routers with no shared L2 domain between them (i.e. each router is
> connected to both firewalls).
> 
> My real goal is not sharing load but supporting asymmetrical routing,
> because the firewalls announce the customer network to the core using
> an IGP. If I am not missing anything I could use OSPF and give a lower
> cost to the port with the higher VRRP priority.
> This way I would be able to use normal active/passive conntrack
> replication.

If this can guarantee that only one firewall filters all the traffic or
that the packets follow a symmetrical path in the filtering, that should
be fine.

BTW, I'd appreciate if you send me a couple of lines describing how to
do that so that I can add it to the user manual. I get an email about
OSPF/multi-path routing issues and conntrackd working once a month (at
least), others will appreciate if we can document all possible solutions
in this setup.

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers