My policy route works in 1.3.0 but not in 1.3.2

I’m labbing a scenario and have run into some sort of a bug but I’m not clear on how best to proceed in narrowing this down/resolving it where I have a policy route used to next-hop specific traffic over to our site to site VPN. The policy route works perfectly in 1.3.0 but doesn’t in 1.3.2. I’ve tried on a system that was running 1.3.0 and then updated to 1.3.2 and also on a fresh system installed with 1.3.2 and both fail.

Here’s all the players:
Test system: eth0: untagged

L3 Switch1: eth0.2030 # used for internal links between Switch, Router and VPN
L3 Switch1: eth1: vlan untagged # gateway for

VPN Server: eth0.2030

Router1: eth0.2010 # WAN
Router1: eth0.2030

set interfaces ethernet eth0 vif 2010 address ''
set interfaces ethernet eth0 vif 2030 address ''
set interfaces ethernet eth0 vif 2030 policy route 'VPN'
set policy route VPN rule 1004 destination address ''
set policy route VPN rule 1004 set table '10'
set policy route VPN rule 1004 source address ''
set protocols static route next-hop
set protocols static route next-hop
set protocols static table 10 route next-hop

Testing is done via a simple ping from a container with IP to which fails and received a “net unreachable” from my WAN simulators IP > > default route to > PBR next-hops to VPN at
The problem is my ping from is going out the Router default route to which obviously doesn’t know what to do with it.

Any help or insight would be appreciated!

Will it work if you delete destination address from the policy route?

Just tested removing the destination address from my policy route config and it had no affect.

Additional tests done, none of which worked:
Removed destination address to my policy route
Re-added destination address to my policy route
Added additional rules to match any local IP to local IP traffic
Added additional rule to match all ICMP traffic

Enabled logging on each and on the default drop and I never see the ping attempts show up in the logs. I’m stumped here.

Require more tests
But as workaround could you remote policy route from the interface 2030
and use

set policy local-route rule 100 set table '10'
set policy local-route rule 100 source ''

Unfortunately I’ve also tried that, having the VPN policy route applied to that interface as well with no effect.

Something wrong with your config or topology, interfaces connections (maybe DNAT or something else)
policy local-route works should always work and you don’t need to attach any other policy
All source traffic with source must go via table 10
Try to dump traffic on interfaces

sudo ip rule show
sudo ip route show table 10

Set some 10.6.x.x to the local router and ping with this source address

My apologies, I misread your last comment. I did not try a local-route option before. I just did and that’s allowing traffic to pass through so that’s progress.
I don’t see an option to specify a destination however on the policy local_route so right now everything sourced from 10.6.X.X is going out that table which next-hops to our VPN server. Is there another options to fitter this?

Match destination will be available in the next LTS release 1.3.3

Are you sure no sNAT is done in the middle?
While pinging from host/container to, do some tcpdump in the router in order to check router is receiving icmp with proper source address.

sudo tcpdump -i eth0.2030 icmp