Date: Sat, 29 Dec 2012 14:57:15 -0600 From: Paul Dokas <dokas@dokas.name> To: freebsd-pf@freebsd.org Subject: Re: [SOLVED]: nc: connect to b:b:b:b::1:1 port 53 (tcp) failed: Operation timed out Message-ID: <50DF592B.1030600@dokas.name> In-Reply-To: <5FA24BDE-D6EE-4C3F-B0DE-BC5CBE9EA7A8@odo.in-berlin.de> References: <14C709A3-B608-44C3-B12F-5F6790AA60DC@odo.in-berlin.de> <50DEDA01.4060103@cyberleo.net> <CA%2B7WWSdLu-P0-65eGWr9aiL-Rdv0_GCBUODsq5Xw5wh%2BcZcNtQ@mail.gmail.com> <5FA24BDE-D6EE-4C3F-B0DE-BC5CBE9EA7A8@odo.in-berlin.de>
index | next in thread | previous in thread | raw e-mail
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."
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50DF592B.1030600>