[Swan] R: R: R: R: Packets dropped strangely

[libreswan91 at iotti.biz]

> -----Messaggio originale-----
> Da: Swan <swan-bounces at lists.libreswan.org> Per conto di
> libreswan91 at iotti.biz
> Inviato: domenica 14 ottobre 2018 09:26
> A: 'Paul Wouters' <paul at nohats.ca>
> Cc: swan at lists.libreswan.org
> Oggetto: [Swan] R: R: R: Packets dropped strangely
> 
> > -----Messaggio originale-----
> > Da: Paul Wouters <paul at nohats.ca>
> > Inviato: domenica 14 ottobre 2018 01:49
> > A: libreswan91 at iotti.biz
> > Cc: swan at lists.libreswan.org
> > Oggetto: Re: R: [Swan] R: Packets dropped strangely
> >
> > On Tue, 9 Oct 2018, libreswan91 at iotti.biz wrote:
> >
> > > ]# cat /proc/net/xfrm_stat
> > > XfrmInError                     0
> > > XfrmInBufferError               0
> > > XfrmInHdrError                  0
> > > XfrmInNoStates                  2
> > > XfrmInStateProtoError           0
> > > XfrmInStateModeError            0
> > > XfrmInStateSeqError             0
> > > XfrmInStateExpired              0
> > > XfrmInStateMismatch             0
> > > XfrmInStateInvalid              69
> > > XfrmInTmplMismatch              119
> > > XfrmInNoPols                    13
> > > XfrmInPolBlock                  0
> > > XfrmInPolError                  0
> > > XfrmOutError                    0
> > > XfrmOutBundleGenError           0
> > > XfrmOutBundleCheckError         0
> > > XfrmOutNoStates                 275
> >
> > anything non-null points to a problem. But these numbers are not reset
> after
> > you restart libreswan, only when you restart the kernel. A few of
> > those
> can
> > happen at times during race conditions, but if you do a ping to
> > something that fails these numbers should not increase per ping.
> > Of that happens, there is a real problem since libreswan thinks there
> > is a policy or state and gave it to the kernel but the kernel disagrees.
> >
> > Paul
> 
> After weeks of testing, I think there is such a problem, at least on
CentOS7
> with the provided kernel and libreswan :)
> 
> The only thing I am sure of, is that when I do my test in the failing
condition, it
> is the XfrmInTmplMismatch counter that gets increased. Just for clarity, I
do
> my test with "nc -v -s 10.250.14.254 172.16.74.193 5681"
> since ping is not accepted on the remote site.
> My box is actually a router/firewall, and the problem was reported by my
> users. Then for clarity I made the tests with iptables rules flushed, no
clients
> connected, and using nc from the firewall. But I know that if I try to
simulate
> the problem with a client in my local lan, dropwatch indicates a drop in
> another kernel function than tcp_v4_rcv. I can make the tests and report
it
> back, including the xfrm_stat counter that gets increased when the packet
> should be routed and not accepted.

I made a test by trying a connecion to the faling address and port from a
node in the local lan. The increasing counter is still XfrmInTmplMismatch.
The kernel function reported by dropwatch is ip_forward+1d0
(0xffffffffb6e386b0).

If I can make more tests, please tell me. One surprising thing for me is
that I have lots of other firewalls made with the same software, but never
had this issue.  I tried to change the hardware, with no benefit.

Thank you, regards
Luigi