This article provides a workaround for the issue of packets dropped due to zone mismatch, in the case of a dual ISP environment.

Deployment scenario:



On Router A, the outgoing interface is fe-0/0/1, which is in zone U1 and the traffic for the internal web server comes in via fe-0/0/2 , which is in another zone U2. During the flow, on the reverse route lookup to the source, there is a zone mismatch:

Aug 29 18:59:49 18:59:49.905634:CID-0:RT: route lookup: dest-ip 10.3.3.1 orig ifp fe-0/0/2.0 output_ifp fe-0/0/1.0 orig-zone 9 out-zone 8 vsd 0
Aug 29 18:59:49 18:59:49.905634:CID-0:RT:Reject route in make_nsp_ready_no_resolve. zone mismatch
Aug 29 18:59:49 18:59:49.905634:CID-0:RT: route to 10.1.1.1
Aug 29 18:59:49 18:59:49.905634:CID-0:RT: route lookup failed: dest-ip 10.3.3.1 orig ifp fe-0/0/2.0 output_ifp fe-0/0/1.0 fto 0x44a6a830 orig-zone 9 out-zone 8 vsd 0
Aug 29 18:59:49 18:59:49.905634:CID-0:RT: packet dropped, pak dropped since re-route failed

A simple solution would be to move both fe-0/0/1 and fe-0/0/2 to the same security zone. In this case, though the incoming and outgoing interfaces are different, as they are in the same security zone, traffic will pass. If moving to the same zone is not an option, there is a workaround.

Workaround:

Apply a source NAT rule from zone U2 to zone T. Apply a firewall filter to match the traffic with the destination address and route it to a virtual router, where traffic will be rerouted via the same interface, through which packets enter.

interfaces {
    fe-0/0/0 {
        unit 0 {
            family inet {
                filter {
                    input workaround;
                }
                address 192.168.1.1/24;
            }
        }
    }

firewall {
    filter workaround {
        term 1 {
            from {
                destination-address {
                    10.2.2.3/32;
                }
            }
            then {
                routing-instance r1;
            }
        }
    }
}

routing-instances {
    r1 {
        instance-type virtual-router;
        interface fe-0/0/2.0;
        routing-options {
            static {
                route 0.0.0.0/0 next-hop 10.2.2.1;
            }
        }
    }
}
[edit security nat]
source {
    pool p1 {
        address {
            10.2.2.3/32;
        }
    }
    rule-set R {
        from zone U2;
        to zone T;
        rule 1 {
            match {
                destination-address 10.2.2.2/32;
            }
            then {
                source-nat {
                    pool {
                        p1;
                    }
                }
            }
        }
    }
}

Now the flow trace will be as follows:

Aug 29 19:05:04 19:05:04.454768:CID-0:RT: make_nsp_ready_no_resolve()
Aug 29 19:05:04 19:05:04.454768:CID-0:RT: route lookup: dest-ip 10.3.3.1 orig ifp fe-0/0/2.0 output_ifp fe-0/0/2.0 orig-zone 9 out-zone 9 vsd 0
Aug 29 19:05:04 19:05:04.454768:CID-0:RT: route to 10.2.2.1