Junos OS

Hey all. Having a bit of trouble setting up a simple destination nat on a j4350 running 9.1es.  I'd like to nat the external IP 72.200.100.50  to the internal IP 10.104.0.8.  Relevant config pasted below:

 show security zones security-zone inside address-book address external_test_ip
72.200.100.50/32;

show security nat destination-nat internal_test_ip
address 10.104.0.8;

show security policies from-zone outside to-zone inside policy test
match {
    source-address any;
    destination-address external_test_ip;
    application junos-ssh;
}
then {
    permit {
        destination-nat {
            internal_test_ip;
        }
    }
}

So trying to ssh to 72.200.100.50 from the outside times out.  What am I missing? does the external interface need to have 72.200.100.50 assigned to it?  Thanks in advance. 

--dave 

So the thing that was really screwing with me was, given that I have lots of possible egress interfaces on these routers and lots of zones that they belong to, how was the router mapping a given external IP to the proper internal zone.  It can't use policy to do this because it has to decide it's egress interface before it parses the policy.  Even it if didn't decide the egress interface first, if more than one policy refers to the nat, which one should the router choose?  It's all sort of non-deterministic.

Anyway, I decided that I was never hitting the policy and had to somehow explicitly define the egress interface for my external IP, so I added a static route for 72.200.100.50 that uses the internal IP as a next hop, so: 

set routing-options  static route 72.200.100.50 next-hop 10.104.0.8

And that seems to have fixed it?   Does that seem like a valid thing to have had to do or am I still missing something?  Quite honestly it seems a little hokey and wierd to me to have to add a  static route for every inbound destination nat. Also this obviously isn't in any of the documentation so..  Yeah did I find the fix or a work-around? 

You might find this KB article useful.

http://kb.juniper.net/KB10458

This article uses PPTP as the example but you can use the destination NAT configuration for your application as well. To understand why you were not hitting the correct policy and why the static route helped, you need to understand the order in which the a packet is processed through flow.

1. First thing that is checked upon seeing a packet in flow is to check if there is already a session for the packet based on source/destination IP and port and ingress/egress interface.The ingress interface isknown at this point. If session is found, then the packet is sent through fast path processing.

2. If no session found then first packet processing is done. A route lookup is performed and assuming there is a route to a next-hop, it will know which egress interface to forward the packet to.

3. Once route lookup determines egress interface we next perform policy lookup. Each transit interface must be bound to a security zone. Thus based on the ingress and egress interfaces we can determine the to-zone from-zone context for the policy lookup.

4. Once policy lookup is done, assuming a policy exists which permits the packet, then any NAT will be applied before packet is forwarded. The packet is then sent through fast path processing and leaves flow.

The above is a bit oversimplified, but generally true. So based the above, step 2 is the reason why you could not reach the destination NAT policy. The route lookup determined that the destination IP was in same zone as the ingress interface. Thus this becomes an intra-zone policy. When you added the static route pointing the next-hop to the inside interface, then this became an inter-zone policy lookup.

Hope thats make sense.

-Richard

Thanks Richard,

I understand that the router determines the egress interface before it parses the security policy, it's what I meant when I said "It can't use policy to do this because it has to decide it's egress interface before it parses the policy" in my second post. 

So, my question is, does it seem 'normal' in juniper-land to maintain a static route for each dst-nat on a router? If you were hired to replace a network guy at a company, logged into the router and saw that it had a static route configured for every dst-nat, would that be something you would shake your head at?

Thanks!

--dave 

Adding a static route is certainly one option. The other option instead of the static route is to have your destination NAT policy be an untrust to untrust policy (as opposed to untrust to trust). Both should work.

-Richard