VyOS ARPing for non-L2 adjacent IP? Trying to Wireguard from non-default VRF

Hi folks! I am building a wireguard tunnel between two VyOS endpoints - one in Vultr and one at home. I’m running 1.2.9S-1 in Vultr and 1.3.2 at home.
My WAN connection (DHCP from cable modem) is landing in the WAN VRF (eth0.50) on my home instance and I am placing the wg1 tunnel in the default VRF with a static interface route with the destination IP of my Vultr endpoint pointing to the WAN interface and VRF. I can’t get the tunnel up. Doing a PCAP, it looks like VyOS is ARPing for the IP of my Vultr cloud instance which makes no sense because it’s not L2 adjacent to my home instance. Why is it not just sourcing the wireguard tunnel from my WAN IP received via DHCP in the WAN VRF? PCAP output and config (with some sanitation) included below.

18:02:47.638660 ARP, Request who-has 23.50.44.55 tell 75.200.135.222, length 28
18:02:47.937530 IP 23.50.44.55.2225 > 75.200.135.222.41657: UDP, length 148
18:02:47.937566 IP 75.200.135.222 > 23.50.44.55: ICMP 75.200.135.222 udp port 41657 unreachable, length 184
18:02:50.710730 ARP, Request who-has 23.50.44.55 tell 75.200.135.222, length 28
18:02:51.734650 ARP, Request who-has 23.50.44.55 tell 75.200.135.222, length 28
18:02:52.758652 ARP, Request who-has 23.50.44.55 tell 75.200.135.222, length 28

$ show configuration
interfaces {
ethernet eth0 {
hw-id 52:54:00:81:49:96
vif 50 {
address dhcp
address dhcpv6
dhcp-options {
}
vrf wan
}
vif 53 {
address 10.39.233.90/31
address XXXX:803:9002:301::1/64
}
vif 113 {
address 10.39.233.13/27
address XXXX:803:9002::13/64
vrf management
}
}
loopback lo {
}
wireguard wg1 {
address 10.51.172.55/31
address XXXX:803:9001:402::2/64
description TUNNEL-TO-USCHI1-BBISP-GW1-WG1
peer USCHI1-BBISP-GW1-WG1 {
address 23.50.44.55
allowed-ips ::/0
allowed-ips 0.0.0.0/0
port 2225
pubkey ****************
}
}
}
nat {
source {
rule 10 {
outbound-interface eth0.50
translation {
address masquerade
}
}
}
}
policy {
prefix-list v4-AS64714-In {
rule 10 {
action permit
prefix 10.39.232.0/23
}
rule 20 {
action permit
prefix 10.51.175.0/24
}
rule 30 {
action permit
prefix 10.16.64.0/20
}
rule 40 {
action permit
prefix 10.51.172.153/32
}
rule 50 {
action permit
prefix 10.51.173.153/32
}
}
route-map v4-AS64714-In {
rule 10 {
action permit
match {
ip {
address {
prefix-list v4-AS64714-In
}
}
}
}
}
}
protocols {
bgp 64715 {
address-family {
ipv4-unicast {
maximum-paths {
ebgp 4
}
}
ipv6-unicast {
maximum-paths {
ebgp 4
}
}
}
neighbor 10.39.233.91 {
address-family {
ipv4-unicast {
route-map {
import v4-AS64714-In
}
soft-reconfiguration {
inbound
}
}
}
description XXXXX
remote-as 64714
}
neighbor XXXX:803:9002:301::2 {
address-family {
ipv6-unicast {
soft-reconfiguration {
inbound
}
}
}
description XXXXX-FW
remote-as 64714
}
}
static {
interface-route 23.50.44.55/32 {
next-hop-interface eth0.50 {
next-hop-vrf wan
}
}
}
vrf management {
static {
route 0.0.0.0/0 {
next-hop 10.39.233.1 {
}
}
route6 ::/0 {
next-hop fe80::1 {
}
}
}
}
}
service {
ssh {
port 22
vrf management
}
}
system {
config-management {
commit-revisions 100
}
console {
device ttyS0 {
speed 115200
}
}
host-name xxxxx-rtr2
login {
user xxxx {
authentication {
encrypted-password ****************
}
}
}
name-server x.x.x.x
name-server x.x.x.x
name-server x.x.x.x
name-server x.x.x.x
ntp {
server x.x.x.x {
}
vrf management
}
syslog {
global {
facility all {
level info
}
facility protocols {
level debug
}
}
}
}
vrf {
name management {
description management_vrf
table 113
}
name wan {
table 150
}
}

With interface route without nexthop ip address it always will send ARP request

So does that mean I am out of luck since this interface is using DHCP? Hard to configure a next-hop IP if it’s going to possibly change. Is there an alternate way to accomplish what I’m trying to? The only reason I’m throwing my WAN into a different VRF is because I will have the default route installed in the default VRF by BGP over the wireguard tunnel and I need the wireguard tunnel to follow the default route via my ISP, but all other traffic should follow default learned via BGP over the wireguard tunnel. Fun I know…

As wireguard is in a different VRF, try routing its encrypted packets through WAN vrf.
(using NAT)
Then you can get rid of next-hop-interface, and use next-hop instead