Date: Wed, 10 Feb 2016 20:51:24 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality Message-ID: <bug-207087-2472-vE00XBxnwg@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-207087-2472@https.bugs.freebsd.org/bugzilla/> References: <bug-207087-2472@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=3D207087 --- 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 simil= ar in the respect that some of your UDP traffic ( your OpenVPN control traffic= for example ) appears to be processed correctly, but other traffic ( your OpenV= PN 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 du= e 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 y= ou describe in your bug report. However, that doesn't necessarily explain your 2nd problem where non-tunnel= ed 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 initi= al 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. --=20 You are receiving this mail because: 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-2472-vE00XBxnwg>