[SOLVED]: nc: connect to b:b:b:b::1:1 port 53 (tcp) failed: Operation timed out

[Paul Dokas]

On 12/29/12 08:31, Michael Grimm wrote:
> I've been told to change my outgoing rule from ...
> 
> | pass out log on $extIF inet6 proto {tcp, udp, icmp6, gre} all modulate state
> 
> ... to ...
> 
> | pass out log on $extIF inet6 proto {tcp, udp, icmp6, gre} all
> 
> ... and that did the trick! No more checksum and timeout errors. Now it works as expected.
> 
> Just for me to learn: What change in code from 9.0 to 9.1 made that first rule break? I used that rule since 7.0, IIRC.


I'll add another data point as this affected me also.

I have a host that I recently upgraded from 9.0 -> 9.1.  Under 9.0, I
could ssh to it without any issues using both ipv4 and ipv6.  However
after upgrading to 9.1, I could no longer access this host via ipv6.  In
/etc/pf.conf under 9.0, the packets were allowed via this line:

  pass in proto tcp from <AUTHORIZED> to <SELF> port 22 modulate state

Now, under 9.1, I had to replace this line with the following to restore
ipv4 and ipv6 connectivity:

  pass in inet proto tcp from <AUTHORIZED> to <SELF> port 22 modulate state
  pass in inet6 proto tcp from <AUTHORIZED> to <SELF> port 22

Thank you for the fix.  I'm also curious about what changed in PF
between 9.0 and 9.1.  Looking over the commits, I see many changes,
several of which affect ipv6, but nothing that would obviously account
for this change in behavior.  I am also no expert on the PF code, so I
could easily be missing something obvious.


The broken behavior that I am seeing goes like this:

  Host A:  FreeBSD 9.1 with ipv4 and ipv6 connectivity
  Host B:  Linux with ipv4 and ipv6 connectivity

  14:42:54.449782 IP6 HostB.23277 > HostA.22: Flags [S], seq 4121331899,
win 65535, options [mss 1440,nop,wscale 9,sackOK,TS val 3181373 ecr 0],
length 0
  14:42:54.449971 IP6 HostA.22 > HostB.23277: Flags [S.], seq
1127207337, ack 4121331900, win 65535, options [mss 1440,nop,wscale
9,sackOK,TS val 3217245253 ecr 3181373], length 0


This is from tcpdump output on host B.  The SYN/ACK packet does make it
to host B, but seems to be silently ignored.

For comparison, here's the same few packets with the fix in place on Host A:

  14:51:58.716186 IP6 HostB.33915 > HostA.22: Flags [S], seq 3905485643,
win 65535, options [mss 1440,nop,wscale 9,sackOK,TS val 3725643 ecr 0],
length 0
  14:51:58.716356 IP6 HostA.22 > HostB.33915: Flags [S.], seq
2791731777, ack 3905485644, win 65535, options [mss 1440,nop,wscale
9,sackOK,TS val 3462082146 ecr 3725643], length 0
  14:51:58.716411 IP6 HostB.33915 > HostA.22: Flags [.], ack 1, win
2049, options [nop,nop,TS val 3725643 ecr 3462082146], length 0

In this case, the 3 way handshake completes.

Paul
-- 
Paul Dokas                                         dokas at dokas.name
======================================================================
Don Juan Matus:  "an enigma wrapped in mystery wrapped in a tortilla."