RSH session issue passing through the Palo Alto

[TranceforLife]

Hi Guys,

Interesting one. 

1x2.1x4.1x4.1x5 makes an initial connection using RSH the 192.168.0.20 then creates a separate RSH session back to the originating server but this always fails as the Palo seems to ignore the rule and NAT that is in place for this.

Any suggestions/advises are welcome.

Thanks

[Raido_Rattameister]

Have not worked with RSH but assuming that reverse connection ports are communicated in the beginning of session (similar to FTP) and this session is not decrypted on firewall (you are not doing SSH proxy) then how should Palo know what ports to open for return traffic?

[TranceforLife]

Hi Raido,

Correct. This session is similar to the FTP session.

Server in Management LAN ( 1x2.1x4.1x4.1x5) initiates a RSH session (port 514) to  the 192.168.2.80 server. They agree another port for return (example tcp port 707). 192.168.2.80 opens a new session to the Server in Management LAN on agreed port.

Details of traffic:

Incoming from 1x2.1x4.1x4.1x5 to 1x2.1x4.1x9.2x2 using RSH
(Management) 1x2.1x4.1x4.1x5 (rsh 514) ----> 1x2.1x4.1x9.2x2 Bidirectional NAT ----> (NPS)192.168.2.80

Outgoing from 192.168.2.80 to 1x2.1x4.1x4.1x5 response to initial packet above connects back to authenticate on agreed port using RSH
(NPS) 192.168.2.80 (rsh 512-1023) ----> Bidirectional NAT 1x2.1x4.1x9.2x2 ----> 1x2.1x4.1x4.1x5 (Management)

[Raido_Rattameister]

NAT is not enough.

Security policy will probably take this traffic down.

Try to create allow any any from 192.168.2.80 to management LAN PC that initiates connection.

If it works then remove this any any rule and set up SSH proxy under decyption tab and test if it keeps on working.

[nikoo]

My guess it will not work as FTP, because it seems like Palo Alto does not have ALG for RSH. https://www.paloaltonetworks.com/documentation/70/pan-os/pan-os/app-id/application-level-gateways

So reverse connection will not be opened automatically - NAT and security rules have to be in place. If you have that, try splitting NAT into two rules (do not use bidirectional), I stumbled upon strange behaviour of bidirectional rule once, but dunno if it the real problem. 

Also try using CLI with #test nat-policy-match and #test security-policy-match to make sure the traffic is hitting it should be hitting. If it is not - check the rules. I think at least RSH should work without decryption in place.

[Roby_Sreejith · Accepted solution]

Can you see the sessions are "PREDICT" in that case, you can try app override if ALG is creating issue.

[TranceforLife]

Hi Vieplis,

l appreciate all your comments. 

So Palo will monitor FTP session/application and should open all agreed ports between client-server.

But why it doesn't for RSH. Initially, it is allowing, but the session that returns back with different ports traffic hits completely wrong rule.

Cheers

[TranceforLife]

Good point Roby. As the system is not alive cannot test it, tomorrow will have more time.

[nikoo]

Yes, for FTP Palo Alto has the knowledge for ALG to work properly and dynamically open data connections based on control traffic.

For RSH it does not have the knowledge of inner workings for RSH, so it does see the first connection and as NAT/Security rulles allows it through - it is allowed further. When RSH creates second session back, Palo Alto has no clue that this second session was derived from the first session - it sees it as a seperate connection and if there are no NAT/Security rules - it is denied. It will not hit the same security rule as first session (it should hit the bidirectional NAT rule though)  unless it is configured to do so. 

Do you have security rule for two way communication? Or just one rule to initiate first session?

[TranceforLife]

Policy from left>right

Management_to_Spock_Khan {
from Management;
source [ 1x2.1x4.1x4.1x5];
source-region none;
to NPS;
destination [ 1x2.1x4.1x9.2x1 1x2.1x4.1x9.2x2 ];
destination-region none;
user any;
category any;
application/service [ any/tcp/any/514 any/tcp/any/544 ];
action allow;
icmp-unreachable: no
terminal yes;

Policy from right>left

ASP_to_Management_Unix {

from NPS;
source [ 192.168.2.161 192.168.2.18 192.168.2.85 192.168.2.80 ];
source-region none;
to Management;
destination 1x2.1x4.1x2.0/21;
destination-region none;
user any;
category any;
application/service rsh/tcp/any/514;
action allow;
icmp-unreachable: no
terminal yes;

[nikoo]

Can you please post a traffic log example which is denied? So we can probably compare it to the security rules. 

[TranceforLife]

Application override resolved the issue. Thank you all for the help