- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
08-25-2013 08:44 PM
Folks.
I'm apparently having a particularly stupid day, because I can;t make something as simple as one-to-one NAT work.
Scenario is this.
I have an IP in my DMZ. I have assigned this IP to a particular server which is hosted on my INSIDE (secure) network.
All I want to do is take this IP address and NAT it to the inside address. Something like this
IP addresses have been changed to protect the stupid (me!).
So - request comes in from the web to 1.2.3.91, and I want to redirect it to 10.100.1.120 - only needs web browsing and PING.
but I can not, for the life of me, get it right.
I've got the following NAT rule
Original packet
Source Zone - Outside
Destination Zone - DMZ
Source Address - Any
Destination Address - 1.2.3.91
Translated Packet
Source Translation : None
Destination translation : 10.100.1.120
The security policy is as follows
Source : Outside
Source Address : Any
Destination : Inside
Destination Address : 10.100.1.120
I'm happy for anyone to point out where I'm being stupid and laugh at me - I know it's something obvious, but I'm banging my head trying to sort out what.
thanks
08-25-2013 09:08 PM
Hello Sir,
Please go through the below mentioned documents.
Understanding PAN-OS NAT >>>>>>> Page No 15
Thanks
08-25-2013 09:26 PM
HULK wrote:
Hello Sir,
Please go through the below mentioned documents.
Understanding PAN-OS NAT >>>>>>> Page No 15
Thanks
Did that before I asked the dumb question. As far as I can tell, what I have now configured matches - and the damn thing still isn't working.
08-25-2013 10:53 PM
Can you try to add a static route for 1.2.3.91/32 reachable through DMZ interface.
Make sure the packets are being received on the firewall using traffic logs.
P.S: Without addition of this static-route ,NAT rule Outside to Outside should be able to translate these packets.
Try refreshing arp table of the upstream router.
>test arp gratuitous ip 1.2.3.91 interface <outside interface>
08-25-2013 11:57 PM
Nadir wrote:
Can you try to add a static route for 1.2.3.91/32 reachable through DMZ interface.
Make sure the packets are being received on the firewall using traffic logs.
Not sure what you mean - add a static route for 1.2.3.91/32 *where*?
I can see *one* packet (session) which made it through, at some point in the past (I've tweaked the config file so many times since then trying different options I've lost track). I've gone back through the config logs and returned the config to exactly what it was back then - once it commits, I'll try again.
Nadir wrote:
P.S: Without addition of this static-route ,NAT rule Outside to Outside should be able to translate these packets.
Try refreshing arp table of the upstream router.
>test arp gratuitous ip 1.2.3.91 interface <outside interface>
The gratuitous arp fails, vis-a-vis
Server error : cannot send gratuitous ARP
Rolling the config back did me no good at all. I'm at an absolute loss here. I *must* be doing something stupid, I just can't figure out what!
08-26-2013 12:03 AM
Please Allow the Original address 1.2.3.91 in the Security rule.
Source : Outside
Source Address : Any
Destination : Inside
Destination Address : 10.100.1.120
Change to :
Source : Outside
Source Address : Any
Destination : Inside
Destination Address : 1.2.3.91
08-26-2013 12:31 PM
Hello Darren,
Could you please provide a snapshot of traffic log for this destination ( internal server IP 10.100.1.120).
Example:
Thanks
08-26-2013 04:04 PM
akawimandan wrote:
Please Allow the Original address 1.2.3.91 in the Security rule.
Source : Outside
Source Address : Any
Destination : Inside
Destination Address : 10.100.1.120
Change to :
Source : Outside
Source Address : Any
Destination : Inside
Destination Address : 1.2.3.91
Done that. I put *both* the inside (RFC1918) address and the outside (real) address in the allowed destinations and it still didn't work. I've now put just the outside address, and still no good.
08-26-2013 05:49 PM
Can you add a packet-filter and monitor the Global counters for the packet-filter for the source IP (Monitor>Packet Filter)
Initiate a PING to the destination (Public DMZ) ,and verify if the packets are making it to the firewall using the following command:
>show counter global filter packet-filter yes delta yes (Run multiple times )
08-26-2013 06:37 PM
HULK wrote:
Hello Darren,
Could you please provide a snapshot of traffic log for this destination ( internal server IP 10.100.1.120).
Example:
Thanks
No, I can't because there is *nothing* in the logs for the internal IP address. Or the external one, for that matter!
08-26-2013 07:00 PM
akawimandan wrote:
Can you add a packet-filter and monitor the Global counters for the packet-filter for the source IP (Monitor>Packet Filter)
Initiate a PING to the destination (Public DMZ) ,and verify if the packets are making it to the firewall using the following command:
>show counter global filter packet-filter yes delta yes (Run multiple times )
Well, I'm definitely able to capture the incoming PING packets going to the destination IP, so I'm not going nuts and losing it somewhere. The PCAP shows it clearly.
Damned if I can figure out WHY this isn't working, though.
08-26-2013 07:14 PM
Hello Darren,
Thanks for the update. As per my understanding, packets are getting dropped before creating the flow into this firewall. So, please follow the instructions given by akawimandan and take an output of >show counter global filter packet-filter yes delta yes (Run multiple times ).
Thanks
08-26-2013 09:13 PM
Well, the packets are definitely being dropped by the firewall.
I've setup 3 PCAP's so far - stage "receive", stage "firewall" and stage "drop".
The "receive' and "drop" stages show packets. The "firewall" stage does not.
The output of the command above is shown below
Global counters:
Elapsed time since last sampling: 192.637 seconds
name value rate severity category aspect description
--------------------------------------------------------------------------------
pkt_sent 1 0 info packet pktproc Packets transmitted
pkt_outstanding 1 0 info packet pktproc Outstanding packet to be transmitted
pkt_alloc 1 0 info packet resource Packets allocated
flow_policy_deny 7 0 drop flow session Session setup: denied by policy
flow_host_pkt_xmt 1 0 info flow mgmt Packets transmitted to control plane
appid_ident_by_icmp 7 0 info appid pktproc Application identified by icmp type
--------------------------------------------------------------------------------
Total counters shown: 6
--------------------------------------------------------------------------------
"Session setup denied by policy" - sounds ominous - which policy is denying it?
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!