Date: Wed, 10 Feb 2016 20:51:24 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality Message-ID: <bug-207087-8-6h86zZH3DM@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-207087-8@https.bugs.freebsd.org/bugzilla/> References: <bug-207087-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087 --- Comment #5 from mgrooms@shrew.net --- I see. They underlying cause is quite possibly unrelated then. As I said, I wasn't trying to hijack your bug report. But the symptom still sounds similar in the respect that some of your UDP traffic ( your OpenVPN control traffic for example ) appears to be processed correctly, but other traffic ( your OpenVPN transport traffic being tunneled ) does not. That smacks of a re-assembly problem. In the latter case, you could have a large inner IP packet size due to the tunnel overhead which would cause the outer IP packet to be fragmented. This would lead to stalls and resets from the client perspective, just as you describe in your bug report. However, that doesn't necessarily explain your 2nd problem where non-tunneled traffic stalls. You can't NAT fragmented packets if you have a re-assembly problem as the required UDP/TCP port values are only available in the initial packet of a fragmented chain. That usually only effects UDP packets but it can still be a problem for TCP if the TCP MSS is large enough as the DNF bit is typically set in the IP header. In any case, good luck with your problem. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-207087-8-6h86zZH3DM>