This community is currently under full moderation, meaning  all posts will be reviewed before appearing in the community. Please expect a brief delay—there is no need to post multiple times. If your post is rejected, you'll receive an email outlining the reason(s). We've implemented full moderation to control spam. Thank you for your patience and participation.

  • 1.  Changing source zone for policy lookup

    Posted 06-24-2021 16:23
    I just cannot figure out the answer about a one fundamental architecture problem, could anyone help a bit?

    This is a bit difficult to explain in words, but maybe the picture helps. So, in a high-end SRX there is a configuration reflected in the picture. The picture is just a simplified concept picture, there are actually hundreds of customer routing-instances and zones and multiple similar zones and instances as the dmz-zone1 in the picture.

    Now when a host in customer1 VRF wants to access a device in the dmz-zone1 VRF (and zone) the following happens:

    1) The packet exits the customer1 instance towards default route, to the untrust VRF.
    2) On the way the packet is source NATed to a public IP address instead of the private one in the customer VRF. Loopback address is used, lo0.0 is placed in untrust zone.
    3) Route lookup in untrust VRF happens and the packet is routed towards dmz-zone1 VRF and reaches the destination host. Also the return route is fine, as the packet now has a public source address and the return packet is routed back to untrust VRF and via NAT to the customer1 host.
    4) However, and this is the problem: The policy lookup is not done untrust->dmz-zone1, but customer1->dmz-zone1. So, any policies that would normally apply to traffic coming from any internet host to the dmz-zone1 host do not apply, and we would need to create a separate policy set for every possible customer zone.

    What we would like to happen is that the packet is treated exactly as it was any other host somewhere in the internet, coming from the untrust zone. Then we could have equal policies from customer zones and the internet towards the dmz services zone only with a single policy set.

    So, is there somehow a  way to.. "cut the source zone lookup chain" so that the packet would seem to come from the zone where the source NAT interface is? Or any other solution to the problem?

    Of course we could solve the problem by placing the customer VRFs and these DMZ services in a different physical device or a logical system interconnecting at the untrust zone, but that we do not want to do in this case. Instead we are trying to find a way to solve the problem inside a single SRX cluster. So, a way to "treat the routing-instances and zones as different devices in perspective of policy lookup" would be the thing.

  • 2.  RE: Changing source zone for policy lookup

    Posted 06-24-2021 16:46
    Hmm, actually I could play around with global policy context and to-zone in the policies? It's not exactly an answer to all of the problems and the global policy list gets a bit ugly, but it could work.

  • 3.  RE: Changing source zone for policy lookup

    Posted 06-26-2021 12:39
    What you are noticing is the expected behavior for the SRX as a whole.  Zone to zone lookup is based on the ingress interface into the SRX and the egress interface out of the SRX.

    So in your case customer-1 to DMZ is the expected match for doing the processing.

    If you create your nat and security policies with this in mind and the order of nat as indicated below you should be able to allow the desired flows with and without nat per your desire.

    Steve Puluka BSEET - Juniper Ambassador
    IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)

  • 4.  RE: Changing source zone for policy lookup

    Posted 06-27-2021 03:27
    Yep, SRX behaviour is familiar, we have been running them for some 10 years in a lot of different use cases. The question was more like how to get around it in this case. :)

    Seems I got two options so far: Either use global policies or run the traffic between the customer instances and the DMZ services via an MX. The later one is actually easy to do, as the "next hop router" in the picture actually consists of two MX routers connected via BGP. Just need to add a second pair of link networks ​there and modify the routing a bit.

    It needs some simulation first though, mostly about the behaviour of static NATs in this case, would like to move also those public addresses to the same route. Need to play around a bit with an vSRX.

  • 5.  RE: Changing source zone for policy lookup

    Posted 06-27-2021 06:13
    If the main issue is when the nat occurs I don't think global policy will help then as it still occurs at the same point in processing. 

    Global policy helps mainly when you want to avoid having to create tons of zone to zone specific policies.

    And in order for global to kick in you have to insure there is no possible zone to zone specific match so it falls through that first and goes to global.  In other works if even one of the zone to zone rules has the "any" address match parameter you probably won't get to the global checks.

    Steve Puluka BSEET - Juniper Ambassador
    IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)