* conntrackd "issue" in asymmetric scenario with TCP vs ICMP
@ 2022-09-02 22:22 Martin Gignac
2022-09-07 14:52 ` Pablo Neira Ayuso
0 siblings, 1 reply; 3+ messages in thread
From: Martin Gignac @ 2022-09-02 22:22 UTC (permalink / raw)
To: netfilter
Hi,
(Apologies in advance if this is not the right place for this question).
I am running conntrackd between two Linux firewalls running on Fedora
35 using the following configuration:
Sync {
Mode FTFW {
ResendQueueSize 131072
PurgeTimeout 60
ACKWindowSize 300
DisableExternalCache On
StartupResync On
}
UDP {
IPv4_address 172.16.1.1
IPv4_Destination_Address 172.16.1.2
Port 3781
Interface bond0
SndSocketBuffer 1249280
RcvSocketBuffer 1249280
Checksum on
}
Options {
TCPWindowTracking Off
ExpectationSync On
}
}
General {
Systemd on
HashSize 32768
HashLimit 131072
LogFile on
Syslog off
LockFile /var/lock/conntrack.lock
UNIX {
Path /var/run/conntrackd.ctl
}
NetlinkBufferSize 2097152
#NetlinkBufferSizeMaxGrowth 8388608
NetlinkBufferSizeMaxGrowth 83886080
NetlinkOverrunResync On
NetlinkEventsReliable Off
EventIterationLimit 100
Filter From Userspace {
Protocol Accept {
TCP
UDP
ICMP
}
Address Ignore {
IPv4_address 127.0.0.1
IPv4_address 172.16.1.0/29
IPv4_address 192.168.1.24/29
IPv6_address ::1
}
}
}
In an asymmetric scenario where incoming traffic flows through
firewall "A" and outgoing traffic through firewall "B", I've noticed
that pings work, but that SSH does not. In the case of pings, the
first ICMP echo reply flowing through firewall "B" sent in response to
the first ICMP echo request is dropped by "B" because the traffic is
"invalid" according to the nft trace, but subequent echo replies make
it through as they are recognized as being part of an existing state.
So far I assumed that the first packet was dropped because "B" hadn't
yet received the [NEW] conntrack state from "A" by the way it received
the echo reply.
However, in the case of an SSH session establishment where the SYN
packet goes through "A" and the SYN-ACK packet goes through "B", nft
trace always shows the SYN-ACK (including retransmissions) as being
dropped because it is "invalid".
Why does the ping reply eventually get recognized as being part of an
established state, but not the SYN-ACK? Is it a misconfiguration in my
conntrackd.conf? Are TCP 3-way handshakes supported by conntrackd in
asymmetric flows?
I'm not sure exactly if I missed some deeper trace I can perform on
the states being sent/received by conntrackd between each firewall. I
thought if I could get more visibility in those that it might become
obvious why the scenario isn't working.
If anyone has hints to help me troubleshoot, or can point to mistakes
in my configuration, my setup, or even my expectations, I would
appreciate it.
Thanks,
-Martin
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: conntrackd "issue" in asymmetric scenario with TCP vs ICMP
2022-09-02 22:22 conntrackd "issue" in asymmetric scenario with TCP vs ICMP Martin Gignac
@ 2022-09-07 14:52 ` Pablo Neira Ayuso
2022-09-07 15:52 ` Martin Gignac
0 siblings, 1 reply; 3+ messages in thread
From: Pablo Neira Ayuso @ 2022-09-07 14:52 UTC (permalink / raw)
To: Martin Gignac; +Cc: netfilter
On Fri, Sep 02, 2022 at 06:22:16PM -0400, Martin Gignac wrote:
> Hi,
>
> (Apologies in advance if this is not the right place for this question).
>
> I am running conntrackd between two Linux firewalls running on Fedora
> 35 using the following configuration:
>
> Sync {
> Mode FTFW {
> ResendQueueSize 131072
> PurgeTimeout 60
> ACKWindowSize 300
> DisableExternalCache On
> StartupResync On
> }
> UDP {
> IPv4_address 172.16.1.1
> IPv4_Destination_Address 172.16.1.2
> Port 3781
> Interface bond0
> SndSocketBuffer 1249280
> RcvSocketBuffer 1249280
> Checksum on
> }
> Options {
> TCPWindowTracking Off
> ExpectationSync On
> }
> }
> General {
> Systemd on
> HashSize 32768
> HashLimit 131072
> LogFile on
> Syslog off
> LockFile /var/lock/conntrack.lock
> UNIX {
> Path /var/run/conntrackd.ctl
> }
> NetlinkBufferSize 2097152
> #NetlinkBufferSizeMaxGrowth 8388608
> NetlinkBufferSizeMaxGrowth 83886080
> NetlinkOverrunResync On
> NetlinkEventsReliable Off
> EventIterationLimit 100
> Filter From Userspace {
> Protocol Accept {
> TCP
> UDP
> ICMP
> }
> Address Ignore {
> IPv4_address 127.0.0.1
> IPv4_address 172.16.1.0/29
> IPv4_address 192.168.1.24/29
> IPv6_address ::1
> }
> }
> }
>
> In an asymmetric scenario where incoming traffic flows through
> firewall "A" and outgoing traffic through firewall "B", I've noticed
> that pings work, but that SSH does not. In the case of pings, the
> first ICMP echo reply flowing through firewall "B" sent in response to
> the first ICMP echo request is dropped by "B" because the traffic is
> "invalid" according to the nft trace, but subequent echo replies make
> it through as they are recognized as being part of an existing state.
> So far I assumed that the first packet was dropped because "B" hadn't
> yet received the [NEW] conntrack state from "A" by the way it received
> the echo reply.
>
> However, in the case of an SSH session establishment where the SYN
> packet goes through "A" and the SYN-ACK packet goes through "B", nft
> trace always shows the SYN-ACK (including retransmissions) as being
> dropped because it is "invalid".
>
> Why does the ping reply eventually get recognized as being part of an
> established state, but not the SYN-ACK? Is it a misconfiguration in my
> conntrackd.conf? Are TCP 3-way handshakes supported by conntrackd in
> asymmetric flows?
>
> I'm not sure exactly if I missed some deeper trace I can perform on
> the states being sent/received by conntrackd between each firewall. I
> thought if I could get more visibility in those that it might become
> obvious why the scenario isn't working.
>
> If anyone has hints to help me troubleshoot, or can point to mistakes
> in my configuration, my setup, or even my expectations, I would
> appreciate it.
Flow should be distributed evenly between routers, pure assymetric
packet-based distribution is prone to race between internal state
updates triggered by packets and the state synchronization itself.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: conntrackd "issue" in asymmetric scenario with TCP vs ICMP
2022-09-07 14:52 ` Pablo Neira Ayuso
@ 2022-09-07 15:52 ` Martin Gignac
0 siblings, 0 replies; 3+ messages in thread
From: Martin Gignac @ 2022-09-07 15:52 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter
Thanks for the clarification Pablo.
Regards,
-Martin
On Wed, Sep 7, 2022 at 10:52 AM Pablo Neira Ayuso <pablo@netfilter.org> wrote:
>
> On Fri, Sep 02, 2022 at 06:22:16PM -0400, Martin Gignac wrote:
> > Hi,
> >
> > (Apologies in advance if this is not the right place for this question).
> >
> > I am running conntrackd between two Linux firewalls running on Fedora
> > 35 using the following configuration:
> >
> > Sync {
> > Mode FTFW {
> > ResendQueueSize 131072
> > PurgeTimeout 60
> > ACKWindowSize 300
> > DisableExternalCache On
> > StartupResync On
> > }
> > UDP {
> > IPv4_address 172.16.1.1
> > IPv4_Destination_Address 172.16.1.2
> > Port 3781
> > Interface bond0
> > SndSocketBuffer 1249280
> > RcvSocketBuffer 1249280
> > Checksum on
> > }
> > Options {
> > TCPWindowTracking Off
> > ExpectationSync On
> > }
> > }
> > General {
> > Systemd on
> > HashSize 32768
> > HashLimit 131072
> > LogFile on
> > Syslog off
> > LockFile /var/lock/conntrack.lock
> > UNIX {
> > Path /var/run/conntrackd.ctl
> > }
> > NetlinkBufferSize 2097152
> > #NetlinkBufferSizeMaxGrowth 8388608
> > NetlinkBufferSizeMaxGrowth 83886080
> > NetlinkOverrunResync On
> > NetlinkEventsReliable Off
> > EventIterationLimit 100
> > Filter From Userspace {
> > Protocol Accept {
> > TCP
> > UDP
> > ICMP
> > }
> > Address Ignore {
> > IPv4_address 127.0.0.1
> > IPv4_address 172.16.1.0/29
> > IPv4_address 192.168.1.24/29
> > IPv6_address ::1
> > }
> > }
> > }
> >
> > In an asymmetric scenario where incoming traffic flows through
> > firewall "A" and outgoing traffic through firewall "B", I've noticed
> > that pings work, but that SSH does not. In the case of pings, the
> > first ICMP echo reply flowing through firewall "B" sent in response to
> > the first ICMP echo request is dropped by "B" because the traffic is
> > "invalid" according to the nft trace, but subequent echo replies make
> > it through as they are recognized as being part of an existing state.
> > So far I assumed that the first packet was dropped because "B" hadn't
> > yet received the [NEW] conntrack state from "A" by the way it received
> > the echo reply.
> >
> > However, in the case of an SSH session establishment where the SYN
> > packet goes through "A" and the SYN-ACK packet goes through "B", nft
> > trace always shows the SYN-ACK (including retransmissions) as being
> > dropped because it is "invalid".
> >
> > Why does the ping reply eventually get recognized as being part of an
> > established state, but not the SYN-ACK? Is it a misconfiguration in my
> > conntrackd.conf? Are TCP 3-way handshakes supported by conntrackd in
> > asymmetric flows?
> >
> > I'm not sure exactly if I missed some deeper trace I can perform on
> > the states being sent/received by conntrackd between each firewall. I
> > thought if I could get more visibility in those that it might become
> > obvious why the scenario isn't working.
> >
> > If anyone has hints to help me troubleshoot, or can point to mistakes
> > in my configuration, my setup, or even my expectations, I would
> > appreciate it.
>
> Flow should be distributed evenly between routers, pure assymetric
> packet-based distribution is prone to race between internal state
> updates triggered by packets and the state synchronization itself.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-09-07 15:52 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-09-02 22:22 conntrackd "issue" in asymmetric scenario with TCP vs ICMP Martin Gignac
2022-09-07 14:52 ` Pablo Neira Ayuso
2022-09-07 15:52 ` Martin Gignac
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox