Project

General

Profile

Bug #3760

reply-to with TCP and IPv6 generates broken checksums

Added by Jim Pingle over 6 years ago. Updated almost 6 years ago.

Status:
Resolved
Priority:
High
Assignee:
Ermal Luçi
Category:
Rules / NAT
Target version:
Start date:
07/15/2014
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.2
Affected Architecture:
All

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.

History

#1 Updated by Jim Pingle over 6 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.

#2 Updated by Jim Thompson over 6 years ago

  • Assignee set to Ermal Luçi

#3 Updated by Ermal Luçi about 6 years ago

  • Status changed from New to Feedback

Merged a patch to correct the regression.

#4 Updated by Chris Buechler about 6 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

#5 Updated by Ermal Luçi about 6 years ago

More testing needed after another change have been merged.

#6 Updated by Matt Bunce about 6 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.

#7 Updated by Matt Bunce about 6 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

#8 Updated by Ermal Luçi about 6 years ago

  • Status changed from New to Feedback

Please test with later coming snapshot since it should have the final fix for this.

#9 Updated by FriendlyFire isnotcool about 6 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. :(

#10 Updated by Ermal Luçi about 6 years ago

Please use the next one.

#11 Updated by Chris Buechler about 6 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.

#12 Updated by FriendlyFire isnotcool about 6 years ago

Same troubles on:
built on Thu Oct 16 09:56:37 CDT 2014

#13 Updated by Ermal Luçi about 6 years ago

Next snapshot should have the fixed of allowing states to match properly.

#14 Updated by Ermal Luçi about 6 years ago

  • Status changed from Confirmed to Resolved

Works correctly now.

#15 Updated by Chris Buechler about 6 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).

#16 Updated by Chris Buechler about 6 years ago

  • Priority changed from High to Very High

#17 Updated by Chris Buechler about 6 years ago

  • Affected Architecture All added
  • Affected Architecture deleted (amd64)

#19 Updated by Chris Buechler almost 6 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).

#20 Updated by Chris Buechler almost 6 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.

#21 Updated by Chris Buechler almost 6 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.

#22 Updated by Ermal Luçi almost 6 years ago

  • Status changed from Confirmed to Feedback

I pushed a fix that should treat this, test with new snapshots.

#23 Updated by Chris Buechler almost 6 years ago

  • Status changed from Feedback to Confirmed

that change made kernel builds fail and was reverted.

#24 Updated by Ermal Luçi almost 6 years ago

  • Status changed from Confirmed to Feedback

Reput back with proper building on snapshots.

#25 Updated by Chris Buechler almost 6 years ago

  • Status changed from Feedback to Resolved

confirmed working, looks good

Also available in: Atom PDF