One-to-One NAT - DMZ to inside - how do I make it work?

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.

One-to-One NAT - DMZ to inside - how do I make it work?

L4 Transporter

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

18 REPLIES 18

L7 Applicator

Apply the NAT from Zone --" Outside" to zone" Outside".  NAT lookup happens  PANFW before translate the original packet ( Public IP address).

Thanks

L7 Applicator

Hello Sir,

Please go through the below mentioned documents.

Understanding PAN-OS NAT >>>>>>> Page No 15

     

Thanks

L7 Applicator

Hello,

Please find below an example of One-to-one NAT.

D-NAT-1.JPG.jpg

D-NAT-2.JPG.jpg

Hope it helps.

Thanks

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.

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>

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!

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

Hello Darren,

Could you please provide a snapshot of traffic log for this destination ( internal server IP 10.100.1.120).

Example:

traffoc-log-example.JPG.jpg

Thanks

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.

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 )

HULK wrote:

Hello Darren,

Could you please provide a snapshot of traffic log for this destination ( internal server IP 10.100.1.120).

Example:

traffoc-log-example.JPG.jpg

Thanks

No, I can't because there is *nothing* in the logs for the internal IP address. Or the external one, for that matter!

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.

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

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?

  • 5206 Views
  • 18 replies
  • 1 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!