This article provides one situation where packets could be dropped when both DST NAT and multiple custom routing-instances are in use, and also provides the solution.
Server--(10.1.1.0/24)-----(reth0.20)SRX(reth0.10)----Internet----Client
If we set Destination NAT and multiple custom routing-instances as below:
set security nat destination pool test address 10.1.1.1/32 set security nat destination rule-set 1 from zone untrust set security nat destination rule-set 1 rule 1 match destination-address 172.16.1.1/32 set security nat destination rule-set 1 rule 1 then destination-nat pool test set routing-instances VR1 instance-type virtual-router set routing-instances VR1 interface reth0.20 set routing-instances VR2 instance-type virtual-router set routing-instances VR2 interface reth0.10 set routing-instances VR2 interface st0.0
Route information:
VR1.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.1.1.0/24 *[Direct/0] 00:58:38 > via reth0.20 10.1.1.1/32 *[Local/0] 00:59:24 Local via reth0.20 VR2.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.1.0/24 *[Direct/0] 00:14:08 > via reth0.10 192.168.1.1/32 *[Local/0] 00:14:08 Local via reth0.10 1.1.1.0/24 *[Direct/0] 00:13:57 > via st0.0 1.1.1.1/32 *[Local/0] 00:14:08 Local via st0.0
We will find the packets dropped from flow traceoption:
RT:flow_first_rule_dst_xlate: DST xlate: 172.16.1.1(12876) to 10.1.1.1(12876), rule/pool id 2/2. << <here, DST NAT worked<br /> RT:[JSF] Do ingress interest check. regd ingress plugins(1) RT:[JSF][0]plugins(0x0) enabled for session = 1098 implicit mask(0x0), service request(0x0) RT:-jsf : no plugin ingress interested for session 1098 RT:flow_first_routing: vr_id 7, call flow_route_lookup(): src_ip 192.168.1.2, x_dst_ip 10.1.1.1, in ifp st0.0, out ifp N/A sp 0, dp 12876, ip_proto 1, tos 0 RT:Doing DESTINATION addr route-lookup RT:Route-lookup for 10.1.1.1 yielded reject NH <<< RT: packet dropped, no route to dest <<<
Add the routing-instance into the security destination nat pool as follows:
set security nat destination pool test routing-instance VR1 commit
Then the traffic will be processed as normal:
RT:flow_first_rule_dst_xlate: DST xlate: 172.16.1.1(13920) to 10.1.1.1(13920), rule/pool id 1/1. RT:[JSF] Do ingress interest check. regd ingress plugins(1) RT:[JSF][0]plugins(0x0) enabled for session = 1145 implicit mask(0x0), service request(0x0) RT:-jsf : no plugin ingress interested for session 1145 RT:flow_first_routing: vr_id 6, call flow_route_lookup(): src_ip 192.168.1.2, x_dst_ip 10.1.1.1, in ifp st0.0, out ifp N/A sp 0, dp 13920, ip_proto 1, tos 0 RT:Doing DESTINATION addr route-lookup RT:flow_ipv4_rt_lkup success 10.1.1.1, iifl 0x50, oifl 0x4d <<< route lookup success RT: routed (x_dst_ip 10.1.1.1) from untrust (st0.0 in 0) to reth0.20, Next-hop: 10.1.1.1 RT:flow_first_policy_search: policy search from zone untrust-> zone trust (0x110,0x3660,0x3660) RT:Policy lkup: vsys 0 zone(9:untrust) -> zone(8:trust) scope:0 RT: 192.168.1.2/2048 -> 10.1.1.1/55949 proto 1 RT: app 0, timeout 60s, curr ageout 60s RT: permitted by policy test(7)