Ok, acontece que a definição da Microsoft de uma VPN site-to-site envolve 2 servidores RRAS conversando entre si e ignorando seus respectivos clientes de rede local.
Minha solução foi obtida parcialmente usando esse conceito de modelo hub-spoke:
O molho secreto está na configuração de endereços IPv4 estáticos nas configurações de rede da interface de discagem por demanda para um IP na respectiva sub-rede de destino e a adição de rotas como esta:
10.150 / 16 tem um servidor RRAS @ 10.150.0.10 e tem uma interface de discagem por demanda com IP estático atribuído como 192.168.150.128.
192.168.150 / 24 tem um servidor RRAS @ 192.168.150.10 e tem sua interface de discagem por demanda com IP estático atribuído como 10.150.0.128.
Isso efetivamente desativa o mecanismo de designação de pool de DHCP / IP, o que faz com que não seja um problema agora.
Rotas:
RRAS @ 10.150.0.10: route add 192.168.150.128 mask 255.255.255.255 10.150.0.128 -p
RRAS @ 192.168.150.10: route add 10.150.0.128 mask 255.255.255.255 192.168.150.128 -p
Esse tráfego bidirecional fixo e agora sou capaz de rastrear / pingar de e para servidores nas LANs.
A Microsoft realmente precisa simplificar a implantação de site para site, onde ambos os servidores RRAS estão atrás de dispositivos de ponta.