Hello Brian,
>> "I thought we eliminated pf(4) as the problem. Technically if you can
negotiate a 3-way handshake and
establish the TCP socket, MTU should be a non-issue."
Yes, well, if I disable pf (pf -d) it still does not work...so, you would
say
that then it cannot be a PF problem... (pass in quick on $ext_if proto tcp
from any to $vpnboxtjec port 22)
I am not quite sure how to use the tun-device ? I included the tcpdump on
the external interface (see below)
# netstat -s | grep -i drop
0 fragments dropped (duplicates or out of space)
0 malformed fragments dropped
0 fragments dropped after timeout
0 output packets dropped due to no bufs, etc.
0 packets dropped due to policy
0 packets were dropped due to full output queue
14 connections closed (including 5 drops) < from LAN works
ok, from External I have to cancel
as nothing
happens (hangs)
0 embryonic connections dropped
4 connections dropped by rexmit timeout < or, if i don't
cancel...it times out
0 connections dropped by keepalive
0 dropped due to overflow
0 dropped due to bucket overflow
0 dropped due to RST
0 dropped due to ICMP unreachable
0 SYNs dropped (no route or no space)
0 dropped due to no socket
0 broadcast/multicast datagrams dropped due to no socket
0 dropped due to missing IPsec protection
0 dropped due to full socket buffers
0 packets dropped due to policy
0 packets were dropped due to full output queue
0 packets dropped due to policy
0 packets were dropped due to full output queue
0 packets were dropped due to full output queue
0 packets were dropped because of no interface/bridge information
0 packets dropped due to policy
0 packets dropped for other reasons
0 packets dropped due to policy
0 packets were dropped due to full output queue
0 fragments dropped (duplicates or out of space)
0 fragments dropped after timeout
0 output packets dropped due to no bufs, etc.
0 messages dropped due to no socket
0 multicast messages dropped due to no socket
0 messages dropped due to full socket buffers
#
#
#
# tcpdump -i xl0 port 22
tcpdump: listening on xl0, link-type EN10MB
16:16:17.410743 myhost.name.com.42282 > 22.4.remotehost.name.com.ssh: S
2653143135:2653143135(0) win 64512 <mss 1210,nop,nop,sackOK> (DF)
16:16:17.411290 22.4.remotehost.name.com.ssh > myhost.name.com.42282: S
1958807557:1958807557(0) ack 2653143136 win 16384 <mss 1250,nop,nop,sackOK>
16:16:17.460713 myhost.name.com.42282 > 22.4.remotehost.name.com.ssh: . ack
1 win 65340 (DF)
16:16:17.487840 22.4.remotehost.name.com.ssh > myhost.name.com.42282: P
1:22(21) ack 1 win 16940
16:16:17.541512 myhost.name.com.42282 > 22.4.remotehost.name.com.ssh: P
1:28(27) ack 22 win 65319 (DF)
16:16:17.545681 22.4.remotehost.name.com.ssh > myhost.name.com.42282: P
22:426(404) ack 28 win 16940
16:16:17.608985 myhost.name.com.42282 > 22.4.remotehost.name.com.ssh: P
28:312(284) ack 426 win 64915 (DF)
16:16:17.657875 22.4.remotehost.name.com.ssh > myhost.name.com.42282: P
426:438(12) ack 312 win 16940
16:16:17.819652 myhost.name.com.42282 > 22.4.remotehost.name.com.ssh: . ack
438 win 64903 (DF)
16:16:21.854017 myhost.name.com.42282 > 22.4.remotehost.name.com.ssh: P
312:332(20) ack 438 win 64903 (DF)
16:16:21.855649 22.4.remotehost.name.com.ssh > myhost.name.com.42282: P
438:450(12) ack 332 win 16940
16:16:22.049609 myhost.name.com.42282 > 22.4.remotehost.name.com.ssh: . ack
450 win 64891 (DF)
16:16:25.285174 myhost.name.com.42282 > 22.4.remotehost.name.com.ssh: P
332:732(400) ack 450 win 64891 (DF)
16:16:25.301708 22.4.remotehost.name.com.ssh > myhost.name.com.42282: P
450:462(12) ack 732 win 16940
16:16:25.354857 myhost.name.com.42282 > 22.4.remotehost.name.com.ssh: P
732:784(52) ack 462 win 64879 (DF)
16:16:25.358121 22.4.remotehost.name.com.ssh > myhost.name.com.42282: P
462:474(12) ack 784 win 16940
16:16:25.408989 myhost.name.com.42282 > 22.4.remotehost.name.com.ssh: P
784:796(12) ack 474 win 64867 (DF)
16:16:25.430208 22.4.remotehost.name.com.ssh > myhost.name.com.42282: P
474:678(204) ack 796 win 16940 [tos 0x10]
16:16:26.472279 myhost.name.com.42282 > 22.4.remotehost.name.com.ssh: P
784:796(12) ack 474 win 64867 (DF)
16:16:26.472322 22.4.remotehost.name.com.ssh > myhost.name.com.42282: . ack
796 win 16940 [tos 0x10]
16:16:26.930032 22.4.remotehost.name.com.ssh > myhost.name.com.42282: P
474:678(204) ack 796 win 16940 [tos 0x10]
16:16:28.589784 myhost.name.com.42282 > 22.4.remotehost.name.com.ssh: P
784:796(12) ack 474 win 64867 (DF)
16:16:28.589831 22.4.remotehost.name.com.ssh > myhost.name.com.42282: . ack
796 win 16940 [tos 0x10]
16:16:29.930037 22.4.remotehost.name.com.ssh > myhost.name.com.42282: P
474:678(204) ack 796 win 16940 [tos 0x10]
16:16:33.008505 myhost.name.com.42282 > 22.4.remotehost.name.com.ssh: P
784:796(12) ack 474 win 64867
16:16:33.008557 22.4.remotehost.name.com.ssh > myhost.name.com.42282: . ack
796 win 16940 [tos 0x10]
16:16:35.930049 22.4.remotehost.name.com.ssh > myhost.name.com.42282: P
474:678(204) ack 796 win 16940 [tos 0x10]
16:16:41.862678 myhost.name.com.42282 > 22.4.remotehost.name.com.ssh: P
784:796(12) ack 474 win 64867
16:16:41.862735 22.4.remotehost.name.com.ssh > myhost.name.com.42282: . ack
796 win 16940 [tos 0x10]
16:16:44.721213 myhost.name.com.42282 > 22.4.remotehost.name.com.ssh: P
796:816(20) ack 474 win 64867
16:16:44.740090 22.4.remotehost.name.com.ssh > myhost.name.com.42282: P
678:698(20) ack 816 win 16940 [tos 0x10]
^C
1963 packets received by filter
0 packets dropped by kernel
#
#
"Oh you're fine with pkill -HUP sshd";
> Yes DRAC on my DELL's but no DRAC overthere :-(
Thing is, its tricky, when I disabled the pf and later enabled it again, I
lost connection.
The VPN then drops, and people get kicked out of there session, yelling in
there language (which
I dont understand luckely :-)
-----Oorspronkelijk bericht-----
Van: Brian A. Seklecki [mailto:[EMAIL PROTECTED]
Verzonden: dinsdag 6 februari 2007 16:09
Aan: forums
CC: misc@openbsd.org
Onderwerp: Re: SSH client (putty) hangs after name/password login
> Hello Brian,
>
> Not quite sure what you mean with pstree...don't know the command and
> no 'man pstree' on my 3.8 system..?
It's in the psmisc/ package
> Note that I no problems logging into the system while on the local
> network (doing this via a PC that I remotely manage). When I do a SSH
> session (via the VPN
> tunnel) on the INSIDE
> of the OBSD box, I get the same problem....(using the same account).
Okay I must be asleep again. I thought we eliminated pf(4) as the problem.
Technically if you can negotiate a 3-way handshake and establish the TCP
socket, MTU should be a non-issue.
What about "netstat -s". Anything suspicious (grep -i drop) for sections
esp: tcp: ip: icmp: etherip:
If you have access via the LAN, what about tcpdump(8) on the tun(4)
interface?
> is
> not the case locaclly....
> Problem here is that this system is 900Km away...if I would stop the
> SSHD (so i could
Normally I'd say to you "Oh you're fine with pkill -HUP sshd"; but that's
because I'm accustomed to out-of-band management like DRAC and mgetty >:}
~BAS
> restart it with debug options....) I will not be able to reach it
> anymore :-(
