Telnet to Linux over VPN

S

SlickNick

Expert Member
Joined
Oct 4, 2005
Messages
1,094
Reaction score
0
Hey guys,

We have a VPN set up here at the company I work for. We use ISA Server 2006 for VPN and general inet access etc.

Now, the VPN works perfectly, the problem comes in when the users at a Company that provides our ERP system connects to the VPN, they then try to telnet into the linux servers in order to do some changes.

One server is running a very old version of Redhat, and the new one uses Fedora, and they can't get onto either.

Now I read some funky fixes, though I don't know if any of those fixes apply to me, as the other people with such problems were using hardware firewalls etc. Do any of you perhaps know of a way to get this to work, or will Putty be better for them to use?
 
VPN creates a tunnel over which you connect. Changing to putty, only changes the client, not any of the underlying transport.

  • Can they ping the server over the VPN after connecting?
  • Is the telnet service running on the server?
  • Is the telnet port open on the firewall?
  • Shouldn't you be using ssh in any case?

After checking the above, let us know what is possible, and what not, and also if the firewall is open for telnet/ssh traffic.
 
They can ping the server yes, they can even log into the web page of the ERP system, just not telnet etc.

I doubt that the firewall allows telnet/ssh traffic, that is something I will look into immediately.

As for using ssh by default. These people are old and set in their ways, and I have suggested to them in the past that they should use ssh, though they still use telnet.

Will keep you updated. Thanks for the reply!
 
Under no circumstances should the firewall be opened for telnet. No matter what they say or do - keep it closed.

(If they force you to open the port for telnet, document it that they understand and acknowledge the risk(s) of using telnet, and that they will not make any claims or court cases against you should their system be compromised as a result).
 
The_Librarian said:
Under no circumstances should the firewall be opened for telnet. No matter what they say or do - keep it closed.

(If they force you to open the port for telnet, document it that they understand and acknowledge the risk(s) of using telnet, and that they will not make any claims or court cases against you should their system be compromised as a result).
Click to expand...

Hmmm, I'm not really opening telnet to the world, I just created an access rule, that enables telnet and ssh for our VPN and internal users.

Now just for them to test and see if it works.
 
The problem with telnet, is that anybody with a network sniffer will be able to see usernames and passwords, as it is transmitted in clear text.

Most hacking is done from inside an organization, so I would really try very hard to get them so use ssh. If they use putty, it will work exactly like telnet, you just select a different port.
 
I see. Well in that case, I will be sending off a mail to them now, regarding the risks, and informing them that telnet sessions won't be available.
 
Nod said:
The problem with telnet, is that anybody with a network sniffer will be able to see usernames and passwords, as it is transmitted in clear text.

Most hacking is done from inside an organization, so I would really try very hard to get them so use ssh. If they use putty, it will work exactly like telnet, you just select a different port.
Click to expand...

Not only usernames and passwords, the entire data stream is in cleartext.

Putty encrypts the data stream as well.

It is not that difficult to use.
 
Just a thought, can you as a "local" user telnet into the server?, just asking.
If these systems work on telnet chances are that they use a TERM that might not be completely ssh friendly, like compaq, ah how I sometimes miss SCO, NOT!!!!
 
Yup, internally we can telnet without any problems. The access rule on ISA worked. They could get in over the VPN, and they were able to complete their work.

I have informed them of the risks, and gave them a disclaimer.
 
sometimes the internal ip address range can clash quite badly, causing weird anomalies like this...

i.e. they are 192.168.0.xxx and you are 192.168.0.xxx and now the routes are a bit messed up because some packets wont have a clue where to go.

to resolve, one of you changes address range, or get a firewall that supports mapped ip's
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X