cannot telnet in a VPN tunnel, why?
Michelle
I have set up a VPN tunnel between 2 Sonic Wall routers. From
location A, I can access network shared drives located at location B.
But from location A, I cannot telnet to any Solaris UNIX workstations
located at location B. Whenever I use telnet, I get error about
cannot open port 23.
Does Sonic Wall lock out port 23? Any suggestions how to fix this
problem? Thanks.
Dave Uhring
> I have set up a VPN tunnel between 2 Sonic Wall routers. From
> location A, I can access network shared drives located at location B.
> But from location A, I cannot telnet to any Solaris UNIX workstations
> located at location B. Whenever I use telnet, I get error about
> cannot open port 23.
By default, Solaris disables telnet.
> Does Sonic Wall lock out port 23? Any suggestions how to fix this
> problem? Thanks.
Learn *why* telnet is disabled. man inetadm.
Richard B. Gilbert
You could try being a little less cryptic. man inetadm does not refer
to telnet!
Now clearly you do not want to be sending passwords "en clair" over the
internet but it may be an acceptable risk on a LAN.
The OP may be on an isolated LAN or he may not care if the whole world
knows his password.
FWIW telnet works on my S10 box. I don't recall doing anything to
reenable it . . . .
sunburn_$ uname -a
SunOS sunburn 5.10 Generic_118833-36 sun4u sparc SUNW,Ultra-5_10
sunburn_$ telnet sunblok
Trying 192.168.1.20...
Connected to sunblok.
Escape character is '^]'.
SunOS 5.8
login:
Dave Uhring
> Dave Uhring wrote:
>> Learn *why* telnet is disabled. man inetadm.
>>
>
> You could try being a little less cryptic. man inetadm does not refer
> to telnet!
Really! It seemed simpler than svcs(1) and svcadm(1M). telnet can be
enabled or disabled using either inetadm or svcadm.
> Now clearly you do not want to be sending passwords "en clair" over the
> internet but it may be an acceptable risk on a LAN.
The OP is using a VPN so passwords and data are encrypted. But a hostile
user on the LAN can see both in the clear. That is why I recommended that
the OP learn why in.telnetd is disabled by default. I *did* assume from
the OP's previous articles that her system is S10.
> The OP may be on an isolated LAN or he may not care if the whole world
> knows his password.
Do we really want yet another compromised UNIX system spamming the
universe?
> FWIW telnet works on my S10 box. I don't recall doing anything to
> reenable it . . . .
During installation of S10 you were given the option to open or close
network services, but you are using the S10 telnet client to a system
which did have in.telnetd enabled by default. The client is always
available.
Michelle
Sorry, I need to make this clearer.
So from location B, sitting at a Windows PC, I can telnet and I can
ping
to that UNIX station located at location B.
But from location A through the VPN tunnel, sitting at a Windows PC,
I cannot telnet and I cannot ping to the same UNIX station located at
location B.
Dave Uhring
> On Sep 19, 9:01 am, Dave Uhring <daveuhr...@yahoo.com> wrote:
>> On Fri, 19 Sep 2008 08:40:32 -0700, Michelle wrote:
>> > Does Sonic Wall lock out port 23? Any suggestions how to fix this
>> > problem? Thanks.
>>
>> Learn *why* telnet is disabled. man inetadm.
>
> Sorry, I need to make this clearer.
>
> So from location B, sitting at a Windows PC, I can telnet and I can
> ping to that UNIX station located at location B.
OK, then the UNIX host does have in.telnetd enabled.
> But from location A through the VPN tunnel, sitting at a Windows PC,
> I cannot telnet and I cannot ping to the same UNIX station located at
> location B.
Looks like your firewall is blocking both tcp/23 and icmp. Not a Solaris
problem then.
Is port 22 on the Sonic Wall open to location A. If so you can use PuTTY
to gain terminal access to the UNIX hosts at location B.
Michelle
Currently at location B, all Windows PC's can map a network drive to
the UNIX station
using an NFS client software.
So from location A, in order to map a network drive through the VPN
tunnel, and telnet to the UNIX
station at location B, I just need to make port 23 open up on both
Sonic Wall routers, and the problem
will be solved?
Dave Uhring
From your description of the problem, yes. However, the firewall may well
already be configured to allow passage of IP traffic on port 22 (ssh) and
it will probably be far easier and more secure for you to simply use PuTTY
instead of telnet.
David Combs
Dave Uhring <daveu...@yahoo.com> wrote:
>
>During installation of S10 you were given the option to open or close
>network services, but you are using the S10 telnet client to a system
>which did have in.telnetd enabled by default. The client is always
>available.
>
Someday "real soon now" I will be installing s10 -- so, when it asks
that question -- to open or close network services -- what should
I answer, and why?
Thanks,
David
Dave Uhring
It depends to a large extent on just how exposed your system will be. If
it's on a private subnet with *all* other hosts and users being trusted
then turning on all network services would probably cause no problems.
Do you really want, for instance, rsh or telnet access?
Richard B. Gilbert
If you leave network services available, you make the machine vulnerable
to attack via the network. For some situations the risk is
unacceptable! For others the threat is low or the consequences of
successful penetration are not serious enough to justify the
inconvenience. YMMV. The general rule is that you disable services you
do not plan to use.
My machines at home are fully enabled. If you can gain access to my
home network, you can try to attack them. (Lots of luck!!!!!)
Before I retired, we relied on our firewall to protect against external
threats and lived with the risk of employees trying to hack our systems.
The rule was that hacking our systems was cause for instant termination
of your employment without notice, severance pay, or any other
amenities! Hacking by employees was not a problem!
Richard B. Gilbert
Sometimes you do and sometimes not! At my last job, we handled much of
the system administration by logging into the Solaris machines from our
Windoze desktops. All but two of the Solaris systems were workstations
running a typesetting application. 99% of the system administration was
fscking the file system when somebody dumped power! The two servers
seldom needed attention; they lived in the data center and were on a UPS.
There are situations where you cannot allow casual access over the net
and, in such cases, you have to lock things down so it can't happen.
Dave Uhring
> Dave Uhring wrote:
>> Do you really want, for instance, rsh or telnet access?
>
> Sometimes you do and sometimes not! At my last job, we handled much of
> the system administration by logging into the Solaris machines from our
> Windoze desktops.
Clear-text passwords on a network with hubs in almost any work environment
is nothing but an invitation to big problems. But it does require having
somebody in authority with even the smallest of clues to understand the
implications.
But that's not my problem anymore. I've used ssh with key authentication
on my own network since 1999 when OpenSSH first became available. Not
having to enter a password for remote access is convenient.
Richard B. Gilbert
> On Sun, 12 Oct 2008 21:10:11 -0400, Richard B. Gilbert wrote:
>> Dave Uhring wrote:
>
>>> Do you really want, for instance, rsh or telnet access?
>> Sometimes you do and sometimes not! At my last job, we handled much of
>> the system administration by logging into the Solaris machines from our
>> Windoze desktops.
>
> Clear-text passwords on a network with hubs in almost any work environment
> is nothing but an invitation to big problems. But it does require having
> somebody in authority with even the smallest of clues to understand the
> implications.
Why do you assume hubs? At my last job, referred to above, we used
switches rather than hubs. You don't even want to THINK about 300 users
on hubs!
<snip>
Dave Uhring
> Why do you assume hubs? At my last job, referred to above, we used
> switches rather than hubs. You don't even want to THINK about 300 users
> on hubs!
Many corporate networks still have legacy gear. But it's not an
assumption at all. If hubs are used the IP traffic is public.