Rule bypassed when specific ip entered for destination (PanOS 8.1)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Rule bypassed when specific ip entered for destination (PanOS 8.1)

L1 Bithead

I have a rule that has been failing to allow connections to the internal system. To test i've set up the rules below. (IP's obfuscated)
When I run
> test security-policy-match source 1.1.1.206 destination 2.2.2.226 protocol 22
the response is

"External-TEST-OPEN; index: 2" {

 

I am currently able to connect from external to internal with the External-TEST-OPEN, but why is it that when i put in the specific internal system ip that i can't connect?  What am i missing?

 

Rick.
-------------------------------

TEST-Dest-IP {
from untrust;
source 1.1.1.206;
to "Zone Internal";
destination 2.2.2.226;
service any;
application ssh;
action allow;
category any;
rule-type universal;
}
External-TEST-OPEN {
to "Zone Internal";
from untrust;
source [ 1.1.1.206 1.1.1.201];
destination any;
source-user any;
category any;
application ssh;
service any;
hip-profiles any;
action allow;
rule-type universal;
log-setting Log_Forwarding-Traffic;

4 REPLIES 4

L1 Bithead

Is the Palo performing NAT translations for the inbound traffic? If so, is your security policy defining the pre-NAT IP and post-NAT zone?

No, we are not NAT'ing.

L2 Linker

Hi,

can you please set up the command this way:

 

 test security-policy-match from untrust source 1.1.1.206 to Zone Internal destination 2.2.2.226 destination-port 22 protocol 6

 

- if i remember correctly zones names with blanks in it wont work on CLI

- with protocol Palo does not mean the application. Check this:

https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers

 

For the security policies it looks like they have been manipulated. Could you please copy the exact output, for related policies, of this command?

 

> show running security-policy

 

 

 

Kind regards,
René
// If you like my answer force commit it.

@Rene_Boehme,

The CLI can handle spaces fine, you just have to group them properly so its not escaped. So in the example that you have you would actually need to have it like so.

 

test security-policy-match from untrust source 1.1.1.206 to "Zone Internal" destination 2.2.2.226 destination-port 22 protocol 6

 

  • 2665 Views
  • 4 replies
  • 0 Likes
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!