- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
05-16-2013 06:14 AM
Hi all!
I have a new policy that I pushed yesterday that was a total failure and any help you can offer would be appreciated.
We have a policy that looks like this:
Source <Internal IP addresses>
Destination <Negate Region US>
Application <unknown-tcp, unknown-udp>
DENY
However, it is catching and DENYing all unknown-tcp and unknown-udp regardless of Destination Country. We have some internal applications used by our customers that this blocks as I haven't been able to classify all applications we use in house as of yet.
This logic seems like it should be working, am I doing something wrong?
Thanks,
Benc
05-16-2013 07:17 AM
What if you did an allow rule to the US above the rule that's not working, and then do your negate rule directly after it?
05-16-2013 08:13 AM
I don't want to create policy sprawl, I would rather keep it in one rule.
05-16-2013 08:25 AM
Did you check the destination country from IP address you want to pass through?
You can check it as follow.
> show location ip 1.1.1.1
If your customer's IP address is not US, I think that's expected behavior.
05-16-2013 08:27 AM
Our customer's IP space was internal space, they are the source. The destination was definitely an IP in the US and it still got blocked.
05-16-2013 08:31 AM
Honestly it's frustrating to even make suggestions here because you won't even just try some of the suggestions. Do the 'show location ip' command and let us see what the PA thinks the destination country is. Try tossing in the "policy sprawl" rule just to see if it works.
If you won't at least just try some things to see if they make a difference or reveal the problem, then there's no point in asking for help, right?
05-16-2013 09:22 AM
If it is internal space (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) it will not be seen as the United States. The location is seen as "Reserved", as seen by the command given by egearhart.
If the destination address is an IPv6 address, it may not yet be supported.
When you look at the traffic logs for that traffic, how many packets are seen in the c2s and s2c flows? You can also check the session id (CLI command: show session id 123456) that is present in the logs to see what application it is identified as and which rule it is hitting.
Hope this helps,
Greg Wesson
05-16-2013 10:43 AM
I apologize as apparently I was not being clear enough.
In the traffic logs, this rule is blocking ALL unknown-tcp and udp traffic, even the traffic that has a Destination Country of US.
Here is my rule with the non-public bits removed in set notation. It is in our security post-rules for our Internet traffic.
"Block unknown to non-US" from any
"Block unknown to non-US" to any
"Block unknown to non-US" source "<Internal Private Address Space>"
"Block unknown to non-US" destination US
"Block unknown to non-US" source-user any
"Block unknown to non-US" category any
"Block unknown to non-US" application unknown-tcp
"Block unknown to non-US" application unknown-udp
"Block unknown to non-US" service any
"Block unknown to non-US" hip-profiles any
"Block unknown to non-US" negate-source no
"Block unknown to non-US" negate-destination yes
"Block unknown to non-US" action deny
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!