I want my telnet back!

Showing results for 
Show  only  | Search instead for 
Did you mean: 

I want my telnet back!

L0 Member

Don't get me wrong, I really like PAN-OS 5, but why did they take my favorite troubleshooting tool away?

The PA is the new device in our environment and if anything is not working all blame on the 'new guy'.

User claims: 'since we have the new firewall I can't get to webpage xyz anymore' 

Admin: A quick telnet from the PA to xyz on port 80 is timing out?

Admins answer: Sorry Sir, the webpage is either down or somebody upstream is blocking the access. Not even the firewall can get there.

Actually, if they re-enable it (the underlying BusyBox certainly still supports it) it would be really cool if we could specify a source interface like for ping and traceroute.

Am I the only one who's missing telnet or it it worth an RFE?


L6 Presenter

According to the PAN-OS_5.0_CLI_Reference_Guide.pdf the command is still there in PANOS 5.0:


Opens a Telnet session to another host.




8bit {no | yes} |

port <value> |

host <value>



+ 8bit — Use 8-bit data path (no or yes)

+ port — Specifies the port to connect to on the remote host (0-65535)

* host — Specifies the host name or IP address of remote host

Sample Output

The following command opens a Telnet session to the host using 8-bit data.

username@hostname> telnet 8bit

Required Privilege Level

superuser, vsysadmin, deviceadmin

Hmm, not on my box as a logged on superuser.

admin@PA-200> telnet

Unknown command: telnet

admin@PA-200> show system info

hostname: PA-200







mac-address: b4:0c:25

time: Wed Dec 12 15:51:34 2012

uptime: 23 days, 22:32:00

family: 200

model: PA-200

sw-version: 5.0.0


The telnet command was removed from PAN-OS version 5. This is shown in the "Changes to default behavior" section of the release notes. Here's the line in question:

• The telnet command is no longer available in the PAN-OS CLI.

As for why this has been removed, I do not know specifically. If the CLI guide still shows it as available, it should be removed to reflect that decision.

Edit: I can confirm that the currently posted CLI guide does not reference a telnet option. The original document did, but that was removed.


Message was edited by: Greg Wesson

Is it possible for you to find out why it was removed (and if its possible for it to return) and update this thread?

The CLI guide for 5.0 I was referring to was created 2012-11-12 16:36:08 and modified 2012-11-12 16:37:19 (seen in the pdf-properties since the document seems to lack version information in the text).

L4 Transporter

I agree!

Why remove telnet?!

I participated in the beta test of 5.0 and asked the same question.

PaloAlto responded that telnet was removed because of "potential security vulnerability".

Fair enough answer, but they should at least make it possible to turn on if needed at our own risk.

And I don't really buy the "potential security vulnerability" argument since there is still possible to enable telnet on the management interface and management profiles 😉

Jo Christian

/Jo Christian

"potential security vulnerability", seriously? I think I have other problems if somebody already has CLI access to my box than worrying about him having telnet access.




Thanks for your support. Seems that we are the only 2 people that are missing telnet. I doubt that it will be enough to convince Palo Alto to bring it back.

Was worth a try.



Thanks for pointing this out. I will miss it as well.



I don't think many of the users with "big" PA's (4000&5000) have upgraded to 5.0 yet.

There will probably be some more people missing telnet when that happends.

I have contacted our SE regarding this issue. You should do the same 🙂

Jo Christian

/Jo Christian

L1 Bithead

I'll add a +1 for the return of a Telnet client please.  We're just starting our PAN-OS journey but I can see where this would be a big issue for troubleshooting.  I'll mention it to our SE as well.

I guess the security reason is that IF someone hacks your PA box (because you didnt protect the mgmt-interface enough or did something else bad) then the attacker shouldnt be able to use your hacked PA box as a jumpbox to reach further into your internal networks.

However from a troubleshooting point of view I totally agree with you that telnet (or something similar) is needed.

What if PA removes the fullblown telnet client but instead replace it with some extension to the test command?

Like a test-ip command or such that could take a syntax such as:

srcip (default

srcport (default random >1023)

dstip (must be specified)

dstport (must be specified)

flags (optional like syn, ack, psh, fin, rst etc)

mode (default oneshot, other mode(s) are: handshake)

where mode would be if it should send just one packet or if it should complete a tcp handshake. Like mode=oneshot, mode=handshake.

this way one could make the PA to send a syn packet to a specific host/port and then see if you get any syn-ack (or such like rst, fin-ack or something else) in return? The return stuff would be so you dont have to run tcpdump on some other device along the road between the PA and the device which has troubles.

L2 Linker

I also miss the removed telnet-client for troubleshooting purposes.

Quite useful for testing any tcp-port reachability or smtp-tests from the box.

I`m waiting for a statement from the SEs about that.

Implementing the feature like a test-command as mikand suggested would be nice feature!


Thank you for the constructive input. I still can't agree on the security issue of telnet being available in the OS.

Before removing it from the OS it should be removed as a logon method to the Palo Alto itself. I consider the possibility to logon in 'cleartext' to the core security devices in my network as a major security issue. Luckily it can easily be disabled for the OS login.

If somebody nevertheless manages to get unauthorized access to the Palo Alto box, he/she will have (or can grant him/herself) full access with or without a telnet client being present.

The test command would be a valuable improvement for troubleshooting, but would not be able to fully replace a telnet client. Beside a quick port connectivity test, you can use it also to fully test smtp or http (or other none encrypted) communication assuming a little protocol knowledge.

However, I would be willing to surrender telnet for (complete removal also as a logon method) for a connectivity testing tool that has the mentioned functionality.



Bare minimum would be to provide an alternative to test a TCP port openess like 'tcptest' ?

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!