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 0.0.0.0)
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.
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.
I talked to my SE and he confirmed that there is a pending RFE matching the suggestion of mikand.
He added me to that request and wanted to link this thread there as well.
So no telnet, but a connectivity testing utility.
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 Live Community as a whole!
The Live Community thanks you for your participation!