As far as I know, nothing has changed in the environment. At one time, it
all worked well.
But I can't speak for Comcast and whether things have changed on their end.
One other person does some work for us remotely and they have been having
difficulties with access to the Windows Server and with doing file
transfers.
I don't think it's just one thing. Things, they keep changing all around us.
Tom
-----Original Message-----
From: Bahrs, Art
Sent: Thursday, April 21, 2011 12:32 PM
To: Tom Hula ; [log in to unmask]
Subject: RE: Remote VPN Access Problems
Hi Tom :)
Ok... I have to ask the InfoSec Question.... What has changed in your
environment?
Check for any and all changes performed since the last time this worked.
Also, does anyone else connect the way you are having troubles with? If
there are others and they are not having problems then you may be able to
eliminate areas that are not specific to you. (ie user accounts & rights,
routing table entries, proxy rules, etc..)
Thanks
Art "Proxies are our friends... like the Government is our Friend! Hehehe"
Bahrs
Art Bahrs, CISSP
Security Engineer (Oregon Region)
(503) 216-2722
-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On Behalf
Of Tom Hula
Sent: Thursday, April 21, 2011 9:27 AM
To: [log in to unmask]
Subject: Re: Remote VPN Access Problems
Yes, RDP does work, but I have some end-users that don't have that
available to them, nor do I wish to make it available. They have always
been able to connect directly without any issues.
Most people are using Telnet. Since I started using the latest version
of Minisoft, VT has worked better. But I get the same results at home
using Telnet or VT...I will also verify that statement as well tonight.
Tom
-----Original Message-----
From: michael
Sent: Thursday, April 21, 2011 11:33 AM
To: [log in to unmask]
Subject: Re: [HP3000-L] Remote VPN Access Problems
If you can RDP to an internal desktop, why not just connect from there?
I've had issues doing the same, and find that while connected VPN, in
some case Telnet will work when NS/VT will not, usually a network
security problem.
-Mike.
On 04/21/2011 10:01 AM, Tom Hula wrote:
> Internally, we are having no problems accessing the HP3K. Mostly Telnet
> with a few on VT-MGR.
>
> The connection from the Internet is a Comcast Router in Bridge Mode
> connected to a
> Secure Computing Snap Gear 560 which is then connected to an HP ProCurve
> Switch
> which all our workstations, network printers, the HP3K and a Windoze
> Server.
>
> The remote VPN is setup via the Snap Gear router along with an IPSEC
> connection to
> a second site that also uses the Snap Gear router. The second site is
> working fine as well.
> Internally, I can access the Windows Server with Remote Desktop easily as
> well as
> the HP3000. And it used to be that I could also access everything remotely
> using VPN.
>
> From home, I can always connect to our LAN via VPN. Remote Desktop
> connection to the
> Windows Server is no problem from home.
>
> However, I often cannot access the HP3K from my old XP Pro tower and my
> netbook with
> Windows 7 Pro cannot ever access the HP3K. Destination our of reach is the
> error I get.
> I also cannot Ping the address at all when this is the case. Every now and
> then, for some
> reason, I can still get through on the XP Pro tower, but not consistently.
> I can ping all sorts
> of things on our networks, like printers and the switch, but not the HP3K.
>
> I have the HP and the switch port for the HP set up as 100MB/second and
> full duplex and
> NO auto-negotiation.
>
> This setup used to work just fine...nothing has changed on our end.
>
> Here is the latest network info on the HP3000:
>
> ----------------------------------------------------------------------------------
>
> PUB.SYS:netcontrol status
>
> GENERAL TRANSPORT STATUS : THU, APR 21, 2011, 10:55 AM
> TRANSPORT STARTED : SUN, JAN 23, 2011, 8:03 PM
>
> FLAGS : $00000000
> MAX NETWORK INTERFACES : 32
> MAX NODE NAMES : 360
> LOG ID : $00000003
> TRACE INFO : ID : $00000000
> CONTROL PROCESS PORT ID : $FFFFFE3E PIN : 87
> CONTEXT ADDR : $10C.41646008
>
> HOME NETWORK :
> CONFIGURATION FILE : NMCONFIG.PUB.SYS
> TRACE MASK : $00000000
> NODE NAME : SA400.MAIN.SYSTEM
>
> PUB.SYS:nscontrol status
>
> TOTAL NUMBER OF LOCAL NS USERS: 0
> TOTAL NUMBER OF REMOTE NS USERS: 6
> TOTAL NUMBER OF NS USERS: 6
>
> SERVICE TYPE SERVER DESCRIPTION
>
> VTA REMOTE VTSERVER INCOMING STREAM MODE VIRTUAL TERMINAL
> HPIP REMOTE HPIPNS INCOMING CLIENT/SERVER ALLBASE SERVICE
> NSSTATL LOCAL NSSTATUS OUTGOING NSSTATUS SERVICE
> NSSTAT REMOTE NSSTATUS INCOMING NSSTATUS SERVICE
> LOOPBACK REMOTE LOOPBACK INCOMING LOOPBACK SERVICE
> RPML LOCAL DSSERVER OUTGOING REMOTE PROCESS MANAGEMENT
> RPM REMOTE DSSERVER INCOMING REMOTE PROCESS MANAGEMENT
> VT REMOTE VTSERVER INCOMING VIRTUAL TERMINAL
>
> SERVICE STARTED FEATURES
>
> VTA YES
> HPIP YES
> NSSTATL YES
> NSSTAT YES
> LOOPBACK YES
> RPML YES
> RPM YES AUTOLOGON ON
> VT YES
>
> SERVER MIN MAX ACTIVE RESERVED DEBUG PIN JOBNUM STATUS
>
> HPIPNS 0 32767 0 0 OFF
> NSSTATUS 0 300 0 0 OFF
> LOOPBACK 0 300 0 0 OFF
> VTSERVER 0 300 6 0 OFF
> 163 #S495 ACTIVE
> 159 #S494 ACTIVE
> 228 #S493 ACTIVE
> 225 #S491 ACTIVE
> 215 #S492 ACTIVE
> 195 #S471 ACTIVE
> DSSERVER 0 300 0 0 OFF
>
> TOTAL NUMBER OF ACTIVE SERVERS: 6
> TOTAL NUMBER OF RESERVED SERVERS: 0
> TOTAL NUMBER OF SERVERS: 6
> PUB.SYS:linkcontrol @;status=all
> Linkname: DTSLINK Linktype: PCI 100BT Linkstate: CONNECTED
> Physical Path: 0/0/0/0
> Current Station Address: 00-30-6E-26-61-F2
> Default Station Address: 00-30-6E-26-61-F2
> Current Multicast Addresses:
> 09-00-09-00-00-01 09-00-09-00-00-03 09-00-09-00-00-04
> 09-00-09-00-00-06
>
> Transmit bytes 1866936857 Receive bytes
> 1477011269
> Transmits 12205287 Receives unicast
> 9967331
> Transmits no error 12205287 Receives broadcast
> 3285497
> Transmits dropped 0 Receives multicast
> 0
> Transmits deferred 0 Receives no error
> 12150449
> Transmits 1 retry 0 Recv CRC error
> 0
> Transmits>1 retry 0 Recv Maxsize error
> 0
> Trans 16 collisions 0 Recv dropped: addr
> 1102379
> Trans late collision 0 Recv dropped: buffer
> 0
> Trans underruns 0 Recv dropped: descr
> 0
> Carrier losses 0 Recv dropped: other
> 0
> Trans jabber timeout 0 Recv watchdg timeout
> 0
> Link disconnects 0 Recv collisions
> 0
> Link speed 100 Recv overruns
> 0
> Link duplex Full Link auto sensed
> No
> Link mode 100Base-TX Core Secs since clear
> 7570407
>
> --------------------------------------------------------------------------------------------
>
> My IP address, when I VPN in from home, is the same subnet as everyone
> else. I’m thinking it is perhaps timing out? Any ideas would be
> appreciated.
>
> The other interesting thing...if I do a remote desktop to the Windows
> server
> and run a terminal emulator from there, I can get on the HP3000 just fine,
> even
> though I can’t get there directly. That works for me, but not for one of
> our
> applications and not for the other users at all.
>
> Tom Hula
> Victor S. Barnes Company
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
This message is intended for the sole use of the addressee, and may contain
information that is privileged, confidential and exempt from disclosure
under applicable law. If you are not the addressee you are hereby notified
that you may not use, copy, disclose, or distribute to anyone the message or
any information contained in the message. If you have received this message
in error, please immediately advise the sender by reply email and delete
this message.
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
