- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
06-06-2017 06:54 AM
We have PA3000 running 7.1.10
I have issue where tarffic is being droped by the Deny All rule , the last rule even though I have allowed this tarffic to come in ext zone ext zone.
Also for some reason the destination seems to be Internal where as the interafce is the public one.
Does any one have an explanation
06-06-2017 10:10 AM - edited 06-06-2017 10:14 AM
Yes this rule is the isue.
If you need only limited ports to NAT to internal host then change service Any to tcp/80 or whatever port you need.
Or clone this NAT rule.
Move clone rule above it.
Change cloned rule to add service udp/500 and clear out Destination Address Translation under "Translated Packet" tab.
This will exclude incoming IPSec from DNAT.
06-06-2017 07:03 AM
Check if you accidentally apply NAT to traffic that hits your public IP 212.240.x.x port 500.
Maybe you have one-to-one NAT to some internal IP.
06-06-2017 07:24 AM
Hi
I do have the follwing NAT on the public IP . Is the any service the issue ? The transalated packet goes to a internal host
06-06-2017 07:52 AM
The any service wouldn't really be an issue. Maybe take a screenshot of the actual policy in the NAT policy screen instead of this section. If you have the NAT configured bi-directional: yes then you could potentially see exactly what you are describing, as the destination interface then would come across as whatever zone that original source address actually resides in.
06-06-2017 08:05 AM - edited 06-06-2017 08:13 AM
This is screen shot from the NAT Policy screen .
There is alos another NAT policy the other way for this IP , so we do have a bi-directionl NAT
Does this NAT policy not imply that all traffic comeing into this IP is NAted to internal IP
I only have a rule to allow public ip , ext zone > my public ip ext zone for ipsec and IKE.
This is being denied by my Deny All rule , I assume becasue the FW is only seeing the NAted destination (internal) becasue NAT is done before the FW Rules are hit ?
06-06-2017 10:05 AM
Wait so you have two NAT policies instead of just one bi-directional policy. That seems like you could easily make this a small amount easier to manage at the very least.
Yes that would be correct, you would want to modify that security policy to show whatever zone you are actually sending that traffic to. For example since everything public facing is in the DMZ zone I have to have security policies that have the destination zone being DMZ with the destination IP being whatever public IP the NAT associates with.
06-06-2017 10:10 AM - edited 06-06-2017 10:14 AM
Yes this rule is the isue.
If you need only limited ports to NAT to internal host then change service Any to tcp/80 or whatever port you need.
Or clone this NAT rule.
Move clone rule above it.
Change cloned rule to add service udp/500 and clear out Destination Address Translation under "Translated Packet" tab.
This will exclude incoming IPSec from DNAT.
06-06-2017 11:25 AM - edited 06-06-2017 11:26 AM
Well done all,
The issue seems with NAT policy:
As @Raido_Rattameister has already mentioned DNAT exempt is needed.
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!