Bug #3760
closed
reply-to with TCP and IPv6 generates broken checksums
Added by Jim Pingle almost 10 years ago. Updated over 9 years ago.
0%
Description
With two WANs, reply-to will normally ensure connections that enter via alternate WANs return back via the expected path. This does not appear to work on 2.2 where the same configuration worked properly on 2.1.x and before.
The ruleset looks correct, containing the reply-to keyword and the proper gateway, but the packets never exit the firewall. TCP syn from a client on WAN2 enters and it is passed as there is a state table entry, but no reply packet exits any interface, not even via the default gateway.
Tested on amd64, may happen on i386 but needs confirmation.
Updated by Jim Pingle almost 10 years ago
Had default block logging disabled. Turned it back on and saw the reply packets being dropped attempting to exit another unrelated interface. In one test it was the interface with the default gateway. In another test it was lo0. So reply-to is definitely not delivering the packets back to the proper gateway.
Updated by
Updated by Ermal Luçi over 9 years ago
- Status changed from New to Feedback
Merged a patch to correct the regression.
Updated by Chris Buechler over 9 years ago
- Status changed from Feedback to New
still doesn't work on:
FreeBSD 22vpntest.bgn.pfmechanics.com 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #47 30e366f(HEAD)-dirty: Fri Oct 3 10:25:25 CDT 2014 root@pf22-amd64-snap:/usr/obj.amd64/usr/pfSensesrc/src/sys/pfSense_SMP.10 amd64
Updated by Ermal Luçi over 9 years ago
More testing needed after another change have been merged.
Updated by Matt Bunce over 9 years ago
Can I just check, should I be using the pre-compiled snapshot from here:
https://snapshots.pfsense.org/FreeBSD_releng/10.1/amd64/pfSense_HEAD/updates/?C=M;O=D
uname -a gives me:
@@
Also, if things are working correctly, what firewall rules should I have configured? I currently have a machine which is using a VPN and has a LAN rule assigned to route traffic out via the VPN gateway for this specific machine. I also have a NAT port forward set to forward traffic from the VPN external port to the port on the internal machine.
Updated by Matt Bunce over 9 years ago
Whoops - Submitted that last update too early and couldn't figure out how to remove it.
The version I am currently using is:
FreeBSD myrouter.domain 10.1-RC2 FreeBSD 10.1-RC2 #17 d75863a(releng/10.1)-dirty: Tue Oct 14 17:45:18 CDT 2014 root@pf22-amd64-snap:/usr/obj.amd64/usr/pfSensesrc/src/sys/pfSense_SMP.10 amd64
I was wondering if this is the correct snapshot, since I notice in Chris Buechler's post his version mentions "PRERELEASE" where are I am using RC2, is this an issue?
M
Updated by Ermal Luçi over 9 years ago
- Status changed from New to Feedback
Please test with later coming snapshot since it should have the final fix for this.
Updated by FriendlyFire isnotcool over 9 years ago
Damn, i was getting crazy with my servers until i found this report !
I tested "built on Wed Oct 15 11:40:50 CDT 2014".
Still doesn't work. :(
Updated by Chris Buechler over 9 years ago
- Status changed from Feedback to Confirmed
no change on:
2.2-BETA (amd64) built on Thu Oct 16 09:56:37 CDT 2014
SYN comes in correctly, you'll see the SYN ACK get blocked egress out the wrong interface (the one where the default gateway resides) for both v4 and v6.
Updated by FriendlyFire isnotcool over 9 years ago
Same troubles on:
built on Thu Oct 16 09:56:37 CDT 2014
Updated by Ermal Luçi over 9 years ago
Next snapshot should have the fixed of allowing states to match properly.
Updated by Ermal Luçi over 9 years ago
- Status changed from Confirmed to Resolved
Works correctly now.
Updated by Chris Buechler over 9 years ago
- Status changed from Resolved to Confirmed
Return routing is correct now, but TCP checksums are broken (with or without hardware checksum offloading enabled).
Updated by Chris Buechler over 9 years ago
- Priority changed from High to Very High
Updated by Chris Buechler over 9 years ago
- Affected Architecture All added
- Affected Architecture deleted (
amd64)
Updated by Chris Buechler over 9 years ago
Current status is broken checksums on IPv6, source NAT doesn't apply to translate the IP back on IPv4 (though return routing is correct in both cases).
Updated by Chris Buechler over 9 years ago
- Status changed from Confirmed to Feedback
with a kernel Ermal built with his changes as committed earlier, v4 reply-to looks to be fine in all scenarios. Will leave for feedback from others once it's in a snapshot build.
v6 still sends packets with broken checksums, but I'm not sure that's a regression, I'll look at that separately vs. 2.1x.
Updated by Chris Buechler over 9 years ago
- Subject changed from The pf reply-to mechanism appears to be broken on 2.2 to reply-to with TCP and IPv6 generates broken checksums
- Status changed from Feedback to Confirmed
- Priority changed from Very High to High
the most common scenario here is fixed, IPv4 is fine, but IPv6 has regressed from 2.1.x. reply-to with v6 works in pre-2.2 versions, TCP v6 is left with broken checksums currently in 2.2.
Updated by Ermal Luçi over 9 years ago
- Status changed from Confirmed to Feedback
I pushed a fix that should treat this, test with new snapshots.
Updated by Chris Buechler over 9 years ago
- Status changed from Feedback to Confirmed
that change made kernel builds fail and was reverted.
Updated by Ermal Luçi over 9 years ago
- Status changed from Confirmed to Feedback
Reput back with proper building on snapshots.
Updated by Chris Buechler over 9 years ago
- Status changed from Feedback to Resolved
confirmed working, looks good