f



ssh hang after SSH2_MSG_KEXINIT sent

..... but I'm fairly sure it's not an MTU problem and that's the only
thing I can find using Google.

Other client connections to the same host work OK, even from ssh
clients on the same subnet as the ssh client that doesn't work.
Similarly the ssh client that hangs in this one particular case can
connect to other ssh host machines.  One other Fedora 6 Core client
machine on the same network *does* show the same problem, an Ubuntu
and an older Fedora machine don't show the problem.

The ssh client is OpenSSH_4.3p2 on a Fedora Core 6 installation, the
host it can't connect to is OpenSSH_4.4p1 on a Slackware 11 machine.


Having done a google search for this problem I have tried setting the
MTU to 576 on both client and host, no effect at all.  (I simply did
'ifconfig eth0 mtu 576' on both machines as root, is this all that's
needed?)


The client debug reads as follows:-

    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug2: key_type_from_name: unknown key type '-----END'
    debug3: key_read: missing keytype
    debug1: identity file /home/chris/.ssh/id_dsa type 2
    debug1: Remote protocol version 1.99, remote software version OpenSSH_4.4
    debug1: match: OpenSSH_4.4 pat OpenSSH*
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_4.3
    debug2: fd 3 setting O_NONBLOCK
    debug1: SSH2_MSG_KEXINIT sent
    Read from socket failed: Connection reset by peer

There's a long (minutes) pause after the SSH2_MSG_KEXINIT sent.

Does anyone have any suggestions as to what might be the problem?

-- 
Chris Green
0
tinnews (137)
3/14/2007 3:35:12 PM
comp.security.ssh 4228 articles. 0 followers. terra1024 (490) is leader. Post Follow

12 Replies
7606 Views

Similar Articles

[PageSpeed] 2

On Mar 14, 6:35 pm, tinn...@isbd.co.uk wrote:
> .... but I'm fairly sure it's not an MTU problem and that's the only
> thing I can find using Google.
>
> Other client connections to the same host work OK, even from ssh
> clients on the same subnet as the ssh client that doesn't work.
> Similarly the ssh client that hangs in this one particular case can
> connect to other ssh host machines.  One other Fedora 6 Core client
> machine on the same network *does* show the same problem, an Ubuntu
> and an older Fedora machine don't show the problem.
>
> The ssh client is OpenSSH_4.3p2 on a Fedora Core 6 installation, the
> host it can't connect to is OpenSSH_4.4p1 on a Slackware 11 machine.
>
> Having done a google search for this problem I have tried setting the
> MTU to 576 on both client and host, no effect at all.  (I simply did
> 'ifconfig eth0 mtu 576' on both machines as root, is this all that's
> needed?)
>
> The client debug reads as follows:-
>
>     debug3: key_read: missing whitespace
>     debug3: key_read: missing whitespace
>     debug3: key_read: missing whitespace
>     debug3: key_read: missing whitespace
>     debug3: key_read: missing whitespace
>     debug3: key_read: missing whitespace
>     debug3: key_read: missing whitespace
>     debug3: key_read: missing whitespace
>     debug3: key_read: missing whitespace
>     debug3: key_read: missing whitespace
>     debug2: key_type_from_name: unknown key type '-----END'
>     debug3: key_read: missing keytype
>     debug1: identity file /home/chris/.ssh/id_dsa type 2
>     debug1: Remote protocol version 1.99, remote software version OpenSSH_4.4
>     debug1: match: OpenSSH_4.4 pat OpenSSH*
>     debug1: Enabling compatibility mode for protocol 2.0
>     debug1: Local version string SSH-2.0-OpenSSH_4.3
>     debug2: fd 3 setting O_NONBLOCK
>     debug1: SSH2_MSG_KEXINIT sent
>     Read from socket failed: Connection reset by peer
>
> There's a long (minutes) pause after the SSH2_MSG_KEXINIT sent.
>
> Does anyone have any suggestions as to what might be the problem?
>
> --
> Chris Green

Hi there,
I have the same problem, but with open SuSE 10.2.
On the same machine I have windows instalation and it works from there
with putty. Even from windows and VmPlayer with openSuSE 10.2 there is
NO problem connect to one single host.
The connection to other hosts using sshd is ok. Even to windows
servers with copSSH.
I tried change the MTU - it doesn helped.

Here is the client debug:
OpenSSH_4.4p1, OpenSSL 0.9.8d 28 Sep 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version
OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.4
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent

And here it HANGS!!
I tryed putty for linux and the problem persist.
Could this be something with the kernel params?
On suse machines i use different kernels: 2.6.18.2-34-xen, 2.6.18.2-34-
default.

10x to everyone

0
ssabchew (3)
4/24/2007 8:11:11 AM
ssabc...@gmail.com wrote:
> On Mar 14, 6:35 pm, tinn...@isbd.co.uk wrote:
> > .... but I'm fairly sure it's not an MTU problem and that's the only
> > thing I can find using Google.
> >
> > Other client connections to the same host work OK, even from ssh
> > clients on the same subnet as the ssh client that doesn't work.
> > Similarly the ssh client that hangs in this one particular case can
> > connect to other ssh host machines.  One other Fedora 6 Core client
> > machine on the same network *does* show the same problem, an Ubuntu
> > and an older Fedora machine don't show the problem.
> >
> > The ssh client is OpenSSH_4.3p2 on a Fedora Core 6 installation, the
> > host it can't connect to is OpenSSH_4.4p1 on a Slackware 11 machine.
> >
> > Having done a google search for this problem I have tried setting the
> > MTU to 576 on both client and host, no effect at all.  (I simply did
> > 'ifconfig eth0 mtu 576' on both machines as root, is this all that's
> > needed?)
> >
> > The client debug reads as follows:-
> >
> >     debug3: key_read: missing whitespace
> >     debug3: key_read: missing whitespace
> >     debug3: key_read: missing whitespace
> >     debug3: key_read: missing whitespace
> >     debug3: key_read: missing whitespace
> >     debug3: key_read: missing whitespace
> >     debug3: key_read: missing whitespace
> >     debug3: key_read: missing whitespace
> >     debug3: key_read: missing whitespace
> >     debug3: key_read: missing whitespace
> >     debug2: key_type_from_name: unknown key type '-----END'
> >     debug3: key_read: missing keytype
> >     debug1: identity file /home/chris/.ssh/id_dsa type 2
> >     debug1: Remote protocol version 1.99, remote software version OpenSSH_4.4
> >     debug1: match: OpenSSH_4.4 pat OpenSSH*
> >     debug1: Enabling compatibility mode for protocol 2.0
> >     debug1: Local version string SSH-2.0-OpenSSH_4.3
> >     debug2: fd 3 setting O_NONBLOCK
> >     debug1: SSH2_MSG_KEXINIT sent
> >     Read from socket failed: Connection reset by peer
> >
> > There's a long (minutes) pause after the SSH2_MSG_KEXINIT sent.
> >
> > Does anyone have any suggestions as to what might be the problem?
> >
> > --
> > Chris Green
>
> Hi there,
> I have the same problem, but with open SuSE 10.2.
> On the same machine I have windows instalation and it works from there
> with putty. Even from windows and VmPlayer with openSuSE 10.2 there is
> NO problem connect to one single host.
> The connection to other hosts using sshd is ok. Even to windows
> servers with copSSH.
> I tried change the MTU - it doesn helped.
>
> Here is the client debug:
> OpenSSH_4.4p1, OpenSSL 0.9.8d 28 Sep 2006
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Applying options for *
> debug2: ssh_connect: needpriv 0
> debug1: Connecting to xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 22.
> debug1: Connection established.
> debug1: permanently_set_uid: 0/0
> debug1: identity file /root/.ssh/identity type -1
> debug1: identity file /root/.ssh/id_rsa type -1
> debug1: identity file /root/.ssh/id_dsa type -1
> debug1: Remote protocol version 1.99, remote software version
> OpenSSH_3.9p1
> debug1: match: OpenSSH_3.9p1 pat OpenSSH_3.*
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_4.4
> debug2: fd 3 setting O_NONBLOCK
> debug1: SSH2_MSG_KEXINIT sent
>
> And here it HANGS!!
> I tryed putty for linux and the problem persist.
> Could this be something with the kernel params?
> On suse machines i use different kernels: 2.6.18.2-34-xen, 2.6.18.2-34-
> default.
>
> 10x to everyone

I am seeing this problem on Debian testing (lenny) with a 2.6.18
kernel.  Given the previous comments I'm starting to guess it's
something in 2.6.18.  Here is a compiled list so far including my
machines.

Fedora Core 6 -> hangs
2.6.18

OpenSuse 10.2 -> hangs
2.6.18.2-34

Opensuse 10.1 -> works
2.6.16

Xubuntu 7.04  -> works
2.6.20-15.27
OpenSSH_4.3p2 Debian-8ubuntu1, OpenSSL 0.9.8c 05 Sep 2006

Debian Etch  -> hangs
2.6.18.dfsg.1-12etch2
OpenSSH_4.3p2 Debian-9, OpenSSL 0.9.8c 05 Sep 2006

Debian Etch -> works
linux-image-2.6.15-1-486
OpenSSH_4.2p1 Debian-5, OpenSSL 0.9.8a 11 Oct 2005

Debian lenny/sid  -> hangs
Kernel: 2.6.18.dfsg.1-12etch2
OpenSSH_4.3p2 Debian-9, OpenSSL 0.9.8e 23 Feb 2007
OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007

Centos 4 -> works
2.6.9-55.EL
OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003



In my case I am doing the following:

Workstation A -> Nat -> Internet -> Nat -> Workstation B

The ubuntu, opensuse 10.1, Centos, and the debians following the same
network path.

0
wkjam100 (1)
5/25/2007 7:21:20 PM
Hi there,
Finally I fond how to make a workaround!
It is a kernel parameter....bu the real problem is somewhere out
there....on the path between to machines.

so What I've done - I'v changed the kernel parameter
net.ipv4.tcp_rmem.

from
net.ipv4.tcp_rmem = 4096 87380 4194304
to
net.ipv4.tcp_rmem = 4096 87380 207520

And it worked...
I made a systl -a > file.1 on FC6 and then syscl -p file.1 on SuSE
10.2 and it worked...then diff and a lot of test...
Hope somebody can tell actually  what is the problem.
The machines that I cannot ( now I can ) connect via SSH are behind
BSD firewall ( not supported by our company )....and 16 hops.
I presume that between 2 machines there a network unit which cannot
handle big traffic (may be I'm wrong )....but how to say which one?





0
ssabchew (3)
5/28/2007 11:01:21 AM
ssabc...@gmail.com napisa (a):
[...]
> I made a systl -a > file.1 on FC6 and then syscl -p file.1 on SuSE
> 10.2 and it worked...then diff and a lot of test...
> Hope somebody can tell actually  what is the problem.
> The machines that I cannot ( now I can ) connect via SSH are behind
> BSD firewall ( not supported by our company )....and 16 hops.
> I presume that between 2 machines there a network unit which cannot
> handle big traffic (may be I'm wrong )....but how to say which one?

I have the same problem.
Have you found any solution not workaround for this?

I also have a BSD system in beetween (with IPSEC).

Regards,

Dawid SQ6EMM

0
dawszy (2)
6/12/2007 7:29:46 AM
On 2007-06-12, dawszy@gmail.com <dawszy@gmail.com> wrote:
[...]
> I have the same problem.
> Have you found any solution not workaround for this?

Set the MTU to 1492 or less.  See:
http://www.snailbook.com/faq/mtu-mismatch.auto.html

> I also have a BSD system in beetween (with IPSEC).

IPSEC is one of the usual suspects for MTU problems.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
0
dtucker1 (251)
6/13/2007 11:08:08 AM
As I wrote before - I've tested MTU options but only on machines that
I can control!
And it didnt worked.
I don't have any other ideas.
May be you can try change the MTU on the BSD - whre IPSEC is running.
BR,
Stiliyan Sabchew

0
ssabchew (3)
7/2/2007 3:55:23 PM
=

C:\ICW>ssh -vvv 127.0.0.1
OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007
debug2: ssh_connect: needpriv 0
debug1: Connecting to 127.0.0.1 [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /.ssh/identity type -1
debug1: identity file /.ssh/id_rsa type -1
debug1: identity file /.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8
debug1: match: OpenSSH_5.8 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.6
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer


Does anyone have any suggestions as to what might be the problem?
0
gpcgpan
10/23/2013 6:56:37 AM
gpcgpan@gmail.com wrote:

> C:\ICW>ssh -vvv 127.0.0.1
> OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007
> debug2: ssh_connect: needpriv 0
> debug1: Connecting to 127.0.0.1 [127.0.0.1] port 22.
> debug1: Connection established.
> debug1: identity file /.ssh/identity type -1
> debug1: identity file /.ssh/id_rsa type -1
> debug1: identity file /.ssh/id_dsa type -1
> debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8
> debug1: match: OpenSSH_5.8 pat OpenSSH*
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_4.6
> debug2: fd 3 setting O_NONBLOCK
> debug1: SSH2_MSG_KEXINIT sent
> Read from socket failed: Connection reset by peer

I get much the same thing on my employer's laptop at work, but the
same laptop connects just fine when I take it home.  I just assumed
the IT department had gotten paranoid and moved along.  I rarely
need outbound ssh from work.

I'll try again tomorrow to be sure the reset occurs at the same
point.

To the newsgroup:  at what point is the connection encrypted?
That could rule out deep packet inspection by a company router.

-- 
pa at panix dot com
0
pa
10/24/2013 1:11:50 AM
On Thursday, October 24, 2013 at 9:11:50 AM UTC+8, Pierre Asselin wrote:
> gpcgpan@gmail.com wrote:
> 
> > C:\ICW>ssh -vvv 127.0.0.1
> > OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007
> > debug2: ssh_connect: needpriv 0
> > debug1: Connecting to 127.0.0.1 [127.0.0.1] port 22.
> > debug1: Connection established.
> > debug1: identity file /.ssh/identity type -1
> > debug1: identity file /.ssh/id_rsa type -1
> > debug1: identity file /.ssh/id_dsa type -1
> > debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8
> > debug1: match: OpenSSH_5.8 pat OpenSSH*
> > debug1: Enabling compatibility mode for protocol 2.0
> > debug1: Local version string SSH-2.0-OpenSSH_4.6
> > debug2: fd 3 setting O_NONBLOCK
> > debug1: SSH2_MSG_KEXINIT sent
> > Read from socket failed: Connection reset by peer
> 
> I get much the same thing on my employer's laptop at work, but the
> same laptop connects just fine when I take it home.  I just assumed
> the IT department had gotten paranoid and moved along.  I rarely
> need outbound ssh from work.
> 
> I'll try again tomorrow to be sure the reset occurs at the same
> point.
> 
> To the newsgroup:  at what point is the connection encrypted?
> That could rule out deep packet inspection by a company router.
> 
> -- 
> pa at panix dot com

I have the same problem as yours.
0
igzhenjie
2/12/2015 2:27:47 PM
On Tuesday, January 12, 2016 at 11:37:23 AM UTC-6, gil.s...@gmail.com wrote=
:
> On Wednesday, March 14, 2007 at 10:35:12 AM UTC-5, tin...@isbd.co.uk wrot=
e:
> > .... but I'm fairly sure it's not an MTU problem and that's the only
> > thing I can find using Google.
> >=20
> > Other client connections to the same host work OK, even from ssh
> > clients on the same subnet as the ssh client that doesn't work.
> > Similarly the ssh client that hangs in this one particular case can
> > connect to other ssh host machines.  One other Fedora 6 Core client
> > machine on the same network *does* show the same problem, an Ubuntu
> > and an older Fedora machine don't show the problem.
> >=20
> > The ssh client is OpenSSH_4.3p2 on a Fedora Core 6 installation, the
> > host it can't connect to is OpenSSH_4.4p1 on a Slackware 11 machine.
> >=20
> >=20
> > Having done a google search for this problem I have tried setting the
> > MTU to 576 on both client and host, no effect at all.  (I simply did
> > 'ifconfig eth0 mtu 576' on both machines as root, is this all that's
> > needed?)
> >=20
> >=20
> > The client debug reads as follows:-
> >=20
> >     debug3: key_read: missing whitespace
> >     debug3: key_read: missing whitespace
> >     debug3: key_read: missing whitespace
> >     debug3: key_read: missing whitespace
> >     debug3: key_read: missing whitespace
> >     debug3: key_read: missing whitespace
> >     debug3: key_read: missing whitespace
> >     debug3: key_read: missing whitespace
> >     debug3: key_read: missing whitespace
> >     debug3: key_read: missing whitespace
> >     debug2: key_type_from_name: unknown key type '-----END'
> >     debug3: key_read: missing keytype
> >     debug1: identity file /home/chris/.ssh/id_dsa type 2
> >     debug1: Remote protocol version 1.99, remote software version OpenS=
SH_4.4
> >     debug1: match: OpenSSH_4.4 pat OpenSSH*
> >     debug1: Enabling compatibility mode for protocol 2.0
> >     debug1: Local version string SSH-2.0-OpenSSH_4.3
> >     debug2: fd 3 setting O_NONBLOCK
> >     debug1: SSH2_MSG_KEXINIT sent
> >     Read from socket failed: Connection reset by peer
> >=20
> > There's a long (minutes) pause after the SSH2_MSG_KEXINIT sent.
> >=20
> > Does anyone have any suggestions as to what might be the problem?
> >=20
> > --=20
> > Chris Green
>=20
> I know this thread is stale but in case it helps someone, the fix of chan=
ging MTU to 1492 or less fixed the problem for my setup.  The setup is Ubun=
tu 15.10 using vlan on the Ubuntu 15.10 host, and ifcfg-eth1 set to put a s=
tatic ip on the interface on the vlan subnet. I was able to ping from conta=
iner to container over the vlan, but could not ssh, it was hanging at SSH2_=
MSG_KEXINIT sent.  Once the interfaces in the LXC container were set to MTU=
=3D1492 (I set it in both the LXC config file and in the ifcfg-eth1 files) =
ssh worked!  Thanks!!

There's some useful additional information at this link:

https://supportkb.riverbed.com/resources/sites/SUPPORT/content/live/SOLUTIO=
NS/24000/S24051/en_US/book-external.pdf

then go to section "3.5.4. Path MTU detection"
0
gil
1/12/2016 1:01:01 AM
On Wednesday, March 14, 2007 at 10:35:12 AM UTC-5, tin...@isbd.co.uk wrote:
> .... but I'm fairly sure it's not an MTU problem and that's the only
> thing I can find using Google.
>=20
> Other client connections to the same host work OK, even from ssh
> clients on the same subnet as the ssh client that doesn't work.
> Similarly the ssh client that hangs in this one particular case can
> connect to other ssh host machines.  One other Fedora 6 Core client
> machine on the same network *does* show the same problem, an Ubuntu
> and an older Fedora machine don't show the problem.
>=20
> The ssh client is OpenSSH_4.3p2 on a Fedora Core 6 installation, the
> host it can't connect to is OpenSSH_4.4p1 on a Slackware 11 machine.
>=20
>=20
> Having done a google search for this problem I have tried setting the
> MTU to 576 on both client and host, no effect at all.  (I simply did
> 'ifconfig eth0 mtu 576' on both machines as root, is this all that's
> needed?)
>=20
>=20
> The client debug reads as follows:-
>=20
>     debug3: key_read: missing whitespace
>     debug3: key_read: missing whitespace
>     debug3: key_read: missing whitespace
>     debug3: key_read: missing whitespace
>     debug3: key_read: missing whitespace
>     debug3: key_read: missing whitespace
>     debug3: key_read: missing whitespace
>     debug3: key_read: missing whitespace
>     debug3: key_read: missing whitespace
>     debug3: key_read: missing whitespace
>     debug2: key_type_from_name: unknown key type '-----END'
>     debug3: key_read: missing keytype
>     debug1: identity file /home/chris/.ssh/id_dsa type 2
>     debug1: Remote protocol version 1.99, remote software version OpenSSH=
_4.4
>     debug1: match: OpenSSH_4.4 pat OpenSSH*
>     debug1: Enabling compatibility mode for protocol 2.0
>     debug1: Local version string SSH-2.0-OpenSSH_4.3
>     debug2: fd 3 setting O_NONBLOCK
>     debug1: SSH2_MSG_KEXINIT sent
>     Read from socket failed: Connection reset by peer
>=20
> There's a long (minutes) pause after the SSH2_MSG_KEXINIT sent.
>=20
> Does anyone have any suggestions as to what might be the problem?
>=20
> --=20
> Chris Green

I know this thread is stale but in case it helps someone, the fix of changi=
ng MTU to 1492 or less fixed the problem for my setup.  The setup is Ubuntu=
 15.10 using vlan on the Ubuntu 15.10 host, and ifcfg-eth1 set to put a sta=
tic ip on the interface on the vlan subnet. I was able to ping from contain=
er to container over the vlan, but could not ssh, it was hanging at SSH2_MS=
G_KEXINIT sent.  Once the interfaces in the LXC container were set to MTU=
=3D1492 (I set it in both the LXC config file and in the ifcfg-eth1 files) =
ssh worked!  Thanks!!
0
gil
1/12/2016 1:01:01 AM
On Wednesday, June 13, 2007 at 6:08:08 AM UTC-5, Darren Tucker wrote:
> On 2007-06-12, dawszy@gmail.com <dawszy@gmail.com> wrote:
> [...]
> > I have the same problem.
> > Have you found any solution not workaround for this?
> 
> Set the MTU to 1492 or less.  See:
> http://www.snailbook.com/faq/mtu-mismatch.auto.html
> 
> > I also have a BSD system in beetween (with IPSEC).
> 
> IPSEC is one of the usual suspects for MTU problems.
> 
> -- 
> Darren Tucker (dtucker at zip.com.au)
> GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
>     Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.

This worked perfectly for me.  Set MTU to 1492 and ssh works perfectly now.  Thanks Darren!
0
gil
1/12/2016 5:46:29 PM
Reply: