SRX

I have a setup like this:

I have the ge0/0/1.x NAT set up for each respective VLAN, but I want each VLAN to route to it's own public static in the /24. I'm used to Linux where you'd just create 0:0, 0:1 etc and set static IP on them and then route to them, but I doubt this is the way JunOS works? I tried to just add IP addresses to the interface, but I think maybe that's not right?

interface ge-0/0/0.0 {
    address {
        1.2.3.4/32;
        1.2.3.5/32;
        1.2.3.6/32;
    }
}

Then I read I should be setting up a 1-to-1 NAT proxy-arp, so I started working on that and just reset the original /24 IP on ge0/0/0, so I have something like:

proxy-arp {
    interface ge-0/0/0.0 {
        address {
            1.2.3.3/32;
            1.2.3.4/32;
            1.2.3.5/32;
        }
    }
}

then set up some rules like:

set security nat static rule-set untrust-to-vlan10 from zone untrust
set security nat static rule-set untrust-to-vlan10 rule 10 match destination-address 1.2.3.4
set security nat static rule-set untrust-to-vlan10 rule 10 then static-nat prefix 1.2.3.4

Am I approaching this the right way, or what am I missing?

I am not sure but I think you are confusing the junos nat terminology.

static nat is when there is a 1-to-1 relationship between two specific ip addresses and no other address can use that ip.

i.e. 10.10.1.1 to 1.2.3.4 exclusive for all ports

From your description I think what you want is outbound source nat to a pool address.

here your subnet 1010.1.1/24 will use the single address 1.2.3.4 as source nat for their internet traffic and likewise the other subnets.

Destination nat would be when you are port forwarding specific combinations of ip address and port over to an internal address for inbound traffic from the internet to your hosts.

this is a good overview document of examples for all three types of nat

https://kb.juniper.net/library/CUSTOMERSERVICE/technotes/Junos_NAT_Examples.pdf

Thanks for the clarification, it sounds like source NAT is what I was looking for, I will try it.

I can't quite understand whether I need source NAT with or without PAT if I have a lot on internal addresses trying to connect at the same time to the internet over one untrust IP? I want them to keep their port 25 requests as port 25 requests (or am I not understanding what should be happening? I read the docs but it still seems a bit muddy in my mind).

You do need PAT to share the ip address with your subnet. 

I think you are looking at the wrong side of the connection.  Source NAT is changing the ip address and port of the source address.  For smtp transactions the standard port 25 will be on the destination ip address which is untouched.

But if you are running an internal mail server that you want connections from the internet to reach then you will be using destination nat.  When you do this for a mail server you will only change the ip address not the port.

The internal 10.x.x.x/24 addresses will be coming from a pool of DHCP computers in this case, so no mail/web/whatever servers which would need a static inbound port. I just want all the internal computers on VLAN 10 - 10.10.1.0/24 to route to public static 1.2.3.4/24 and all the computers on VLAN 20 - 10.20.1.0/24 to route to public static 1.2.3.5/25 etc. Kind of like a normal home router but with several VLANs on the same LAN port and ge0/0/0 as a single WAN, but with 5 public static IP's  in the same /24 routing to each respective internal VLAN.

Your scenario is standard source nat with a pool definition.

In the example document configure your pools as per page 4.

then setup each subnet per the pools as shown on page 7.

https://kb.juniper.net/library/CUSTOMERSERVICE/technotes/Junos_NAT_Examples.pdf

Okay, so here's what I have:

[edit security nat source]
set pool src-nat-pool20 address 10.20.1.10 to 10.20.1.249
set rule-set 20 from zone 20
set rule-set 20 to zone untrust
set rule-set 20 rule 20 match source-address 0.0.0.0/0
set rule-set 20 rule 20 match destination-address 0.0.0.0/0
set rule-set 20 rule 20 then source-nat pool src-nat-pool20

[edit security nat]
set proxy-arp interface ge-0/0/0.0 address 1.2.3.2 to 1.2.3.5

[edit security policies from-zone 20 to-zone untrust]
set policy 20 match source-address any destination-address any application any
set policy 20 then permit

But now when I head to the LAN port on a downstream router that encapsulates vlan-20, I can't get to the Internet. OTOH, when I ping my downstream router IP from my SRX, it responds, which tells me I *think* that my firewall rules aren't set up right to pass traffic to upstream public statics, is that right? Like I need some policy from untrust to 20? Here's what I have for that:

from-zone untrust to-zone 20 {
    policy deny-all {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            deny;
        }
    }
}

Feels like I might be getting close?

You do not need an inbound policy for this.  Policy is written in the flow direction of the host that initiates the session.  So your policy now is correct.  The next thing to verify there is that the policies from zone 20 to untrust are in an appropriate order and move them if needed.

If this is the only policy then we need to get more information.  The instrucitons here can pull a file showing how the SRX is handling the session packets.

https://kb.juniper.net/InfoCenter/index?page=content&id=KB16110

Okay, I enabled traceoptions like:

set security flow traceoptions file 20debug
set security flow traceoptions flag basic-datapath
set security flow traceoptions packet-filter MatchTraffic source-prefix 10.20.0.0/24 destination-prefix 0.0.0.0/0

and it showed:

May 19 08:01:30 08:01:30.324521:CID-0:RT:  ge-0/0/1.7:10.20.0.3->10.20.0.1, icmp, (8/0)
May 19 08:01:30 08:01:30.324521:CID-0:RT: find flow: table 0x523bd198, hash 14452(0xffff), sa 10.20.0.3, da 10.20.1.1, sp 203, dp 12056, proto 1, tok
16, conn-tag 0x00000000
May 19 08:01:30 08:01:30.324521:CID-0:RT:  no session found, start first path. in_tunnel - 0x0, from_cp_flag - 0
May 19 08:01:30 08:01:30.324521:CID-0:RT:check self-traffic on ge-0/0/1.7, in_tunnel 0x0
May 19 08:01:30 08:01:30.324521:CID-0:RT:retcode: 0x201
May 19 08:01:30 08:01:30.324521:CID-0:RT:pak_for_self : proto 1, dst port 12056, action 0x0
May 19 08:01:30 08:01:30.324521:CID-0:RT:  flow_first_create_session
May 19 08:01:30 08:01:30.324521:CID-0:RT:Save init hash spu id 0 to nsp and nsp2!
May 19 08:01:30 08:01:30.324521:CID-0:RT:First path alloc and instl pending session, natp=0x59cb72e8, id=139732
May 19 08:01:30 08:01:30.324521:CID-0:RT:  flow_first_in_dst_nat: in <ge-0/0/1.7>, out <N/A> dst_adr 10.20.0.1, sp 203, dp 12056
May 19 08:01:30 08:01:30.324521:CID-0:RT:  chose interface ge-0/0/1.7 as incoming nat if.
May 19 08:01:30 08:01:30.324521:CID-0:RT:  packet dropped: for self but not interested
May 19 08:01:30 08:01:30.324521:CID-0:RT:  packet dropped, packet dropped: for self but not interested.

Doesn't that seem to say I don't have a sane rule allowing incoming traffic on ge0/0/1.7? Just trying to understand if my traceoptions logic is sane as well.

It looks like the flow has a destination of 10.20.0.1 which happens to be an ip address assigned to the SRX itself.

May 19 08:01:30 08:01:30.324521:CID-0:RT:  packet dropped: for self but not interested
May 19 08:01:30 08:01:30.324521:CID-0:RT:  packet dropped, packet dropped: for self but not interested.

When the source or destination address is on the actual SRX then the rules are based on the security zone assignments for that interface in host inbound services.  If you need more granular policies then we use the junos-host zone.  But in any case none of the nat or polices for normal zones apply to any traffic with an SRX source/destination address.

Thank you! I had two issues, one was my interface ge0/0/1.7 was in the wrong zone, and also I did:

host-inbound-traffic {
        system-services {
            all;
        }
        protocols {
            all;
        }
    }
    interfaces {
        ge-0/0/1.7;
    }

which now allows me to ping the interface, but not route out to the internet 😕

When I look at traceoptions it seems it's not really trying to map to the public IP (I guess)?

May 22 01:49:25 01:49:25.936483:CID-0:RT: in_ifp <20:ge-0/0/1.7>
May 22 01:49:25 01:49:25.936483:CID-0:RT:setting rtt to:0x657cc050 based on VR ID:0 carried over in flow ctxt,  proto 2(ipv4)
May 22 01:49:25 01:49:25.936483:CID-0:RT:flow_process_pkt_exception: setting rtt in lpak to 0x657cc050
May 22 01:49:25 01:49:25.936483:CID-0:RT: jsf reinj: ctxt flag 0 sess 614180704232 src pid 28 reinj flag 6
May 22 01:49:25 01:49:25.936483:CID-0:RT:host inq check inq_type 0x6
May 22 01:49:25 01:49:25.936483:CID-0:RT:  flow session id 380904
May 22 01:49:25 01:49:25.936483:CID-0:RT:flow_xlate_pak
May 22 01:49:25 01:49:25.936483:CID-0:RT:  post addr xlation: 10.20.0.181->8.8.8.8.
May 22 01:49:25 01:49:25.936483:CID-0:RT:  post addr xlation: 10.20.0.181->8.8.8.8.

The weird part is that the post port xlation seems to start at 10.20.0.x and increments, I'm not sure what's happening:

May 22 01:57:24 01:57:23.944281:CID-0:RT:Doing DESTINATION addr route-lookup
May 22 01:57:24 01:57:23.944281:CID-0:RT:flow_ipv4_rt_lkup success 1.2.3.1, iifl 0x54, oifl 0x48
May 22 01:57:24 01:57:23.944281:CID-0:RT:  routed (x_dst_ip 1.2.3.1) from 20 (ge-0/0/1.7 in 0) to ge-0/0/0.0, Next-hop: 1.2.3.1
May 22 01:57:24 01:57:23.944281:CID-0:RT:flow_first_policy_search: policy search from zone 20-> zone untrust (0x0,0x1d12d2,0x12d2)
May 22 01:57:24 01:57:23.944281:CID-0:RT:Policy lkup: vsys 0 zone(18:20) -> zone(8:untrust) scope:0
May 22 01:57:24 01:57:23.944281:CID-0:RT:             10.20.0.3/2048 -> 1.2.3.1/53036 proto 1
May 22 01:57:24 01:57:23.944281:CID-0:RT:  app 0, timeout 60s, curr ageout 60s
May 22 01:57:24 01:57:23.944281:CID-0:RT:  permitted by policy permit-all(8)
May 22 01:57:24 01:57:23.944281:CID-0:RT:  packet passed, Permitted by policy.
May 22 01:57:24 01:57:23.944281:CID-0:RT:flow_first_src_xlate:  nat_src_xlated: False, nat_src_xlate_failed: False
May 22 01:57:24 01:57:23.944281:CID-0:RT:flow_first_src_xlate:  incoming src port is : 29.
May 22 01:57:24 01:57:23.944281:CID-0:RT:flow_first_src_xlate: src nat returns status: 1, rule/pool id: 2/4, pst_nat: False.
May 22 01:57:24 01:57:23.944281:CID-0:RT:  dip id = 4/0, 10.20.0.3/29->10.20.0.29/24921 protocol 1
May 22 01:57:24 01:57:23.944281:CID-0:RT:  choose interface ge-0/0/0.0(P2P) as outgoing phy if
May 22 01:57:24 01:57:23.944281:CID-0:RT:is_loop_pak: No loop: on ifp: ge-0/0/0.0, addr: 1.2.3.1, rtt_idx:0
May 22 01:57:24 01:57:23.944281:CID-0:RT:-jsf : Alloc sess plugin info for session 618475332531
May 22 01:57:24 01:57:23.944281:CID-0:RT:[JSF]Normal interest check. regd plugins 28, enabled impl mask 0x0
May 22 01:57:24 01:57:23.944281:CID-0:RT:+++++++++++jsf_test_plugin_data_evh: 3
May 22 01:57:24 01:57:23.944281:CID-0:RT:[JSF]Plugins(0x0, count 0) enabled for session = 618475332531, impli mask(0x0), post_nat cnt 0 svc req(0x0)
May 22 01:57:24 01:57:23.944281:CID-0:RT:-jsf : no plugin interested for session 618475332531, free sess plugin info
May 22 01:57:24 01:57:23.944281:CID-0:RT:[JSF]Releasing plugin info blocks
May 22 01:57:24 01:57:23.944281:CID-0:RT:flow_first_service_lookup(): natp(0x56e712f8): app_id, 0(0).
May 22 01:57:24 01:57:23.944281:CID-0:RT:  service lookup identified service 0.
May 22 01:57:24 01:57:23.944281:CID-0:RT:  flow_first_final_check: in <ge-0/0/1.7>, out <ge-0/0/0.0>

 So here's my NAT setup:

nat {
    source {
        pool src-nat-pool20 {
            address {
                10.20.0.10/32 to 10.20.0.249/32;
            }
        }
        rule-set 20 {
            from zone 20;
            to zone untrust;
            rule 20rule {
                match {
                    source-address 10.20.0.0/24;
                    destination-address 0.0.0.0/0;
                }
                then {
                    source-nat {
                        pool {
                            src-nat-pool20;
                        }
                    }
                }
            }
    static {
        rule-set untrust-to-20 {
            from zone untrust;
            rule 20rule {
                match {
                    destination-address 1.2.3.5/32;
                }
                then {
                    static-nat {
                        prefix {
                            1.2.3.5/32;
                        }
                    }
                }
            }
        }
    }
    proxy-arp {
        interface ge-0/0/0.0 {
            address {
                1.2.3.2/32;
                1.2.3.4/32;
                1.2.3.5/32;
            }
        }
    }

Your source nat pool is a private address, for internet acces this is generally a public address as private addresses are not routable.  The pool is the address that your source gets changed to before leaving the SRX.

pool src-nat-pool20 {
            address {
                10.20.0.10/32 to 10.20.0.249/32;
            }
        }

For your static nat rule you are not changing the address at all but using the same address as both the match and the nat address.  Typically you match on the inbound public address and nat this to the desired internal address.

rule 20rule {
                match {
                    destination-address 1.2.3.5/32;
                }
                then {
                    static-nat {
                        prefix {
                            1.2.3.5/32;
                        }

Okay, but all I want to do is route all traffic from the /24 on ge0/0/1.7, which is VLAN 10.20.1.0 all to one public static IP of 1.2.3.5, so do I really need a pool at all?

Once I get that working, I want to similarly route the /24 on ge0/0/1.6 VLAN 10.10.1.0 all to one public static IP of 1.2.3.4 and so on for each respective VLAN.

Okay, but all I want to do is route all traffic from the /24 on ge0/0/1.7, which is VLAN 10.20.1.0 all to one public static IP of 1.2.3.5, so do I really need a pool at all?

By "route" I assume you mean source nat to the public address 1.2.3.5

Source nat uses either the address assigned to the egress interface OR a configured pool address.  So if your egress interface on the SRX for this traffic is 1.2.3.5 then you don't need a pool and use the interface term.

See the top of page 5 here

https://kb.juniper.net/library/CUSTOMERSERVICE/technotes/Junos_NAT_Examples.pdf

Page 6 shows source nat using pool.  The pool can be a single address as you want in your case.  And if the pool address is in the same subnet as the egress SRX interface you need to enable proxy arp on that interface as shown.

Yeah, I was wondering why I need a pool if all I really want to do is assign a 5-IP range to ge0/0/0.1-5 and then route to them based on each VLAN, so do I need a pool at all or can I just add each IP to ge0/0/0.1 = 1.2.3.2, ge0/0/0.2 = 1.2.3.3 and so on and then route each VLAN traffic to that respective IP?

scratched in the notepad, not verified but should work

[edit security nat]
set proxy-arp interface ge-0/0/0.0 address 1.2.3.4 to 1.2.3.6

[edit security nat source]
set pool src-nat-pool10 address 1.2.3.4/32
set pool src-nat-pool20 address 1.2.3.5/32
set pool src-nat-pool30 address 1.2.3.6/32

set rule-set rs10 from zone z10
set rule-set rs10 to zone untrust
set rule-set rs10 rule r10 match source-address 10.10.1/24
set rule-set rs10 rule r10 match destination-address 0.0.0.0/0
set rule-set rs10 rule r10 then source-nat pool src-nat-pool10

set rule-set rs20 from zone z20
set rule-set rs20 to zone untrust
set rule-set rs20 rule r20 match source-address 10.20.1/24
set rule-set rs20 rule r20 match destination-address 0.0.0.0/0
set rule-set rs20 rule r20 then source-nat pool src-nat-pool20

set rule-set rs30 from zone z30
set rule-set rs30 to zone untrust
set rule-set rs30 rule r30 match source-address 10.30.1/24
set rule-set rs30 rule r30 match destination-address 0.0.0.0/0
set rule-set rs30 rule r30 then source-nat pool src-nat-pool30

[edit]
set security address-book ab10 address a10 10.10.1/24
set security address-book ab10 attach zone z10
set security address-book ab20 address a10 10.20.1/24
set security address-book ab20 attach zone z20
set security address-book ab30 address a10 10.30.1/24
set security address-book ab30 attach zone z30

[edit security policies from-zone z10 to-zone untrust]
set policy p10 match source-address ab10
set policy p10 match destination-address any
set policy p10 match application any
set policy p10 then permit

[edit security policies from-zone z20 to-zone untrust]
set policy p20 match source-address ab20
set policy p20 match destination-address any
set policy p20 match application any
set policy p20 then permit

[edit security policies from-zone z30 to-zone untrust]
set policy p30 match source-address ab30
set policy p30 match destination-address any
set policy p30 match application any
set policy p30 then permit

Regards, Wojtek

Okay, I changed some of my rules, but already had ge0/0/0 set up like:

[edit]
show interfaces ge-0/0/0
unit 0 {
    family inet {
        address 1.2.3.2/24;
    }
}

and proxy-arp

[edit security nat]
show proxy-arp
interface ge-0/0/0.0 {
    address {
        1.2.3.3/32;
        1.2.3.3/32;
        1.2.3.4/32;
        1.2.3.5/32;
    }
}

@wdudys, I keep getting an error when trying to attach zone to address book about that not being allow when a global address book is defined, but there is no global address book defined. I posted this to a separate thread  https://forums.juniper.net/t5/SRX-Services-Gateway/mysterious-global-address-book/td-p/327204

Is there some way to do it without an address book?

Thanks to the folks on the separate thread I got it working by using:

set security address-book r20 address r2 range-address 10.20.0.1 to 10.20.0.254
set address-book r20 attach zone r20

And it passes traffic!

If the ip address you are using for source nat is NOT the primary ip address of the egress interface then you do need a pool.

The pool can be a single ip address and you your case needs to be because you will be using a different ip address in each rule for the associated subnets.

I know this in pendantic, but don't refer to this process are "routing"  nat does not "route" any traffic or have any interaction with the routing or forwarding systems.  The traffic will follow the routes created and installed in the table.  Nat is only changing the source address in this case per your rule set.