Issue allowing port 2463

[tglear]

I'm trying to allow port 2463 (lsi-raid-management) traffic from my untrust zone to one of my vlan zones. I have added it to an application group and added a policy for traffic between my untrust zone and vlan zone with that application group. Every other application in the application group is allowed to pass but 2463 is still being blocked by the interzone-default rule. Another policy between to internal vlans allows 2463 traffic to pass. The policy between the two vlans is any-any.

Any ideas why the untust to vlan policy would not allow that port but all other ports in the rule are allowed?

[TranceforLife]

If it is denied by "interzone-default" rule that means your traffic is not hitting your policy. Can you create a separate policy, put it above existing one (where you already allowing another application group). Add only one application "lsi-raid-management" and test again.

[BPry]

@tglear,

Have you verified that this is not re-opening an existing session and getting 'stuck' on the interzone rule? I would try clearing all active sessions for that source/destiantion of the storage array that utilizes tcp/2463 and trying again. That would at least rule out the traffic taking an active session path. 

The command could look like this if this is the only service utilizing 2463. If this is the source port and not the destination port just change it to source-port instead of destination-port. 

clear session all filter destination-port 2463 

[tglear]

I get the same results. Also the source traffic that is being allowed by the policy is from the same IP as the lsi-raid-management so I don't quite understand how it isn't being seen by that policy.

[tglear]

BPry, I cleared the session then reopened the storage manager and I get the same results.

[tglear]

I changed the policy to allow any application and now it is allowing traffic to port 2463 but it tags it as unknown-tcp for the application. Of course I can't really allow everything trough from my untrusted zone.

[bradk14]

forgive me if I'm way off base here or missed something, but just taking a step back...

is the trusted IP a public IP? or do you have a destination NAT rule configured so that the outside can reach it?

is your security policy configured correctly? i.e., post NAT security zones (which sounds correct), but pre-NAT IPs (so your destination IP should be the inside IP, not the public IP).

Can you share your NAT and Security policies?

[tglear]

bradk,

The source address is a trusted IP so there is no NAT.  The source is my laptop on my work LAN and the destination is a VMWare stack that I'm building out for a customer. From my laptop I can connect to the get to anything that I have allowed in the policy except my storage array management. 

[bradk14]

okay, sorry, you had me confused as you said untrusted interface which I took to generally be the internet.

[BPry · Accepted solution]

@tglear,

At that point I might recommend just building out an application override policy since it isn't getting caught by the app-id signature. This would allow you to restrict it to that one port on that one destination.

[tglear]

Thanks BPry. The override policy worked. I'm new to the Palo Alto so I'm just trying to figure it all out. Appreciate the help.

[BPry]

@tglear,

Not a problem. Just keep in mind that when you use application override policies this stops the identification at L4, since you overrode it to statically set an application based on source, destination, and port it does not continue the L7 process.

[tglear]

Thanks for that info BPry. In this case I'm not too concerned because this is temporary while I set this up in our test environment. Eventually it will end up in as an enclave of a closed network and I'm only concerned about limited access from a "trusted" group of people. I am confused as to why I had to do the override in the first place. Can you explain why this port wasn't allowed in the policy while all of the other ports in the policy were? This has to do with the management of a Dell PowerVault. Is there something in the way they implement their protocol that gets rejected at the L7 level?