Summary: | =sys-kernel/vanilla-sources-2.6.39: ssh through an IPSEC vpn fails at expecting SSH2_MSG_KEX_DH_GEX_GROUP | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Anthony Basile <blueness> |
Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://bugzilla.kernel.org/show_bug.cgi?id=36122 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Anthony Basile
2011-05-28 15:03:28 UTC
This happens on both amd64 and i686. I'm doing the git bisect now and will submit upstream. The culprit is commit 2c8cec5c10bced2408082a6656170e74ac17231c. Its summary says: ipv4: Cache learned PMTU information in inetpeer. So messing with the MTU info messes up when tunneling via an IPSEC vpn or possibly other tunnels. This is consistent with the misbehavior of ssh because it is known that mismatched MTU's which cause fragmentation further cause ssh to freeze at "expecting SSH2_MSG_KEX_DH_GEX_GROUP". For reference see http://www.snailbook.com/faq/mtu-mismatch.auto.html I'm working on a reverse patch right now. Simple revert doesn't apply cleanly. I'll bug upstream. Okay reading the code carefully, I see that echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc fixes the problem. So I'm not sure this is a "bug" or a new behavior that ipsec users should be aware of. Let's let upstream decide. (In reply to comment #3) > Okay reading the code carefully, I see that > > echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc > > fixes the problem. So I'm not sure this is a "bug" or a new behavior that > ipsec users should be aware of. Let's let upstream decide. And it breaks other things, such as browsing some web sites. (In reply to comment #4) > (In reply to comment #3) > > Okay reading the code carefully, I see that > > > > echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc > > > > fixes the problem. So I'm not sure this is a "bug" or a new behavior that > > ipsec users should be aware of. Let's let upstream decide. > > And it breaks other things, such as browsing some web sites. echo 1 > tcp_mtu_probing Fixes the ssh via ipsec problem and does not break other things. At this point I'm not sure if this is a "bug" or a new behavior that people setting up ipsec tunnels should be aware of? Any feelings from the kernel@ people? We have a workaround, we can watch the upstream bug and determine if something comes from that where we need to do some work |