IPSEC tunnel problem

[Daniel Hartmeier]

On Thu, May 04, 2006 at 08:03:55PM +0400, Dmitry Andrianov wrote:

> May  4 19:52:53 vrn1 kernel: pf: BAD state: TCP 10.2.0.2:3389
> 10.2.0.2:3389 192.168.10.100:1919 [lo=4162748520 high=4162681620
> win=65535 modulator=0] [lo=0 high=65535 win=1 modulator=0] 2:0 PA
> seq=4162748520 ack=0 len=632 ackskew=0 pkts=245:0 dir=out,fwd

The 'dir=out,fwd' part means that the state was created from a packet
going out on the interface (gif0, I assume), and that the packet being
blocked here was in the same direction.

The 'pkts=245:0' part means that the state entry has so far matched 245
packets flowing in the same direction (out), but 0 in the reverse
direction (in).

And that's the problem, pf is not associating replies with the state
entry. Because of that, the state entry does not advance its sequence
number window (advertised in the replies), and eventually stalls the
connection.

This is probably related to the gif interface. I haven't tried it on
FreeBSD, but for stateful filtering, it would be important that pf sees
packets in both directions on that interface (i.e. SYN outgoing, SYN+ACK
incoming, etc.)

You can test what packets pf sees in what direction on an interface by
replacing the ruleset with a single rule like

  pass log all

and observing pflog0 (with tcpdump, for instance) while establishing a
connection. If only packets of one direction are seen (or both outgoing
and incoming packets are seen as having the same direction), there might
be a problem with pfil hooks in gif.

Daniel