Not sure if I found a bug or if it is related to this one: ⚓ T1218 Static routes not being applied in 1.2 Release
Anyway I have a simple router (no fw, no routing policy, no nat) that has some weird behaviour.
The problem is that a static route does not work, and traffic try to go out using default-gateway even if address is in the same subnet of ethernet interface.
Here you are show interfaces Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down Interface IP Address S/L Description --------- ---------- --- ----------- eth0 10.127.20.71/28 u/u eth1 10.127.10.74/28 u/u WAN lo 127.0.0.1/8 u/u ::1/128 vti1 - A/D vti2 - A/D vti3 - A/D
show ip route 10.127.20.78 Routing entry for 10.127.20.64/28 Known via "connected", distance 0, metric 0, best Last update 00:14:13 ago * directly connected, eth0
vyos@ROUTER:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 06:da:88:01:c0:be brd ff:ff:ff:ff:ff:ff
inet 10.127.20.71/28 brd 10.127.20.79 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::4da:88ff:fe01:c0be/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 02:00:38:f0:00:01 brd ff:ff:ff:ff:ff:ff
inet 10.127.10.74/28 brd 10.127.10.79 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::38ff:fef0:1/64 scope link
valid_lft forever preferred_lft forever
4: ip_vti0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
link/ipip 0.0.0.0 brd 0.0.0.0
5: vti1@NONE: <POINTOPOINT,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ipip 10.127.20.71 peer 10.127.20.49
6: vti2@NONE: <POINTOPOINT,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ipip 10.127.10.74 peer 185.100.111.110
7: vti3@NONE: <POINTOPOINT,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ipip 10.127.10.74 peer 188.125.117.50
vyos@ROUTER:~$ ip r
default via 10.127.10.78 dev eth1 proto static metric 20
10.127.10.64/28 dev eth1 proto kernel scope link src 10.127.10.74
10.127.20.48/28 via 10.127.20.78 dev eth0 proto static metric 20
10.127.20.64/28 dev eth0 proto kernel scope link src 10.127.20.71
vyos@ROUTER:~$ ^C
And also arping result (which seems to work for @Viacheslav
vyos@ROUTER:~$ sudo arping 10.127.20.78 -I eth0 -s 10.127.20.71
ARPING 10.127.20.78 from 10.127.20.71 eth0
Unicast reply from 10.127.20.78 [00:00:5E:00:01:C1] 1.215ms
Unicast reply from 10.127.20.78 [00:00:5E:00:01:C1] 1.212ms
Unicast reply from 10.127.20.78 [00:00:5E:00:01:C1] 1.215ms
^CSent 3 probes (1 broadcast(s))
Received 3 response(s)
I don’t know for sure, it is provider side.
It seems the problem is outside the vyos router.
I already checked with the provider but they said everything is fine by their side.
I did read that blog entry (and forgot about it) and in any case I would not relate these two things.
What is strange is that I have two router with the same (mirrored) configuration.
Both were 1.1.7 until this morning when I updated both at 1.2.4
These two router are just left side and right side of the same VPN and only left side had this problem, no routing problem at right side.
Anyway thank you again.
UPDATED: After some reboot the right side also behaved the same.
Solved with set vpn ipsec options disable-route-autoinstall