Basic routing not working with 2025-Q2 Stream

General questions
1

I have a VyOS 1.5 2025-Q2 Stream install and am struggling with setting up basic routing. Here is my setup:

vyos@vyos# show
interfaces {
ethernet eth0 {
address 72.52.106.135/31
}
ethernet eth1 {
address 66.160.140.240/31
}
}
loopback lo {
}
}
protocols {
static {
route 0.0.0.0/0 {
next-hop 72.52.106.134 {
}
}
}
}

I have a downstream device on the same VLAN as eth1 which has the address 66.160.140.241/31. I can ping it from my VyOS router:

vyos@vyos:~$ ping 66.160.140.241
PING 66.160.140.241 (66.160.140.241) 56(84) bytes of data.
64 bytes from 66.160.140.241: icmp_seq=1 ttl=64 time=0.170 ms
64 bytes from 66.160.140.241: icmp_seq=2 ttl=64 time=0.158 ms
64 bytes from 66.160.140.241: icmp_seq=3 ttl=64 time=0.118 ms
64 bytes from 66.160.140.241: icmp_seq=4 ttl=64 time=0.140 ms
^C
— 66.160.140.241 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3090ms
rtt min/avg/max/mdev = 0.118/0.146/0.170/0.019 ms

No firewalls configured. No NAT rules. Here is the routing table:

vyos@vyos:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure

S>* 0.0.0.0/0 [1/0] via 72.52.106.134, eth0, weight 1, 00:29:49
C>* 66.160.140.240/31 is directly connected, eth1, 00:17:06
C>* 72.52.106.134/31 is directly connected, eth0, 00:34:16

From a device elsewhere on the internet, I can’t ping either 66.160.140.240 or 241. If I watch the traffic on eth0, I can see the icmp request hitting the router, but a reply isn’t being sent:

vyos@vyos:~$ monitor traffic interface eth0 filter “host 202.128.xx.xx”
tcpdump: verbose output suppressed, use -v[v]… for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:20:22.761188 IP 202.128.xx.xx > 66.160.140.240: ICMP echo request, id 16483, seq 22, length 64
13:20:23.764494 IP 202.128.xx.xx > 66.160.140.240: ICMP echo request, id 16483, seq 23, length 64
13:20:24.772036 IP 202.128.xx.xx > 66.160.140.240: ICMP echo request, id 16483, seq 24, length 64
13:20:25.780485 IP 202.128.xx.xx > 66.160.140.240: ICMP echo request, id 16483, seq 25, length 64
13:20:26.872693 IP 202.128.xx.xx > 66.160.140.240: ICMP echo request, id 16483, seq 26, length 64
13:20:27.847930 IP 202.128.xx.xx > 66.160.140.240: ICMP echo request, id 16483, seq 27, length 64
13:20:28.785197 IP 202.128.xx.xx > 66.160.140.240: ICMP echo request, id 16483, seq 28, length 64
13:20:29.789364 IP 202.128.xx.xx > 66.160.140.240: ICMP echo request, id 16483, seq 29, length 64
13:20:30.794434 IP 202.128.xx.xx > 66.160.140.240: ICMP echo request, id 16483, seq 30, length 64
13:20:31.800820 IP 202.128.xx.xx > 66.160.140.240: ICMP echo request, id 16483, seq 31, length 64
13:20:32.804260 IP 202.128.xx.xx > 66.160.140.240: ICMP echo request, id 16483, seq 32, length 64
13:20:34.277517 IP 202.128.xx.xx > 66.160.140.241: ICMP echo request, id 21603, seq 0, length 64
13:20:35.276759 IP 202.128.xx.xx > 66.160.140.241: ICMP echo request, id 21603, seq 1, length 64
13:20:36.407176 IP 202.128.xx.xx > 66.160.140.241: ICMP echo request, id 21603, seq 2, length 64
13:20:37.293962 IP 202.128.xx.xx > 66.160.140.241: ICMP echo request, id 21603, seq 3, length 64
13:20:38.288119 IP 202.128.xx.xx > 66.160.140.241: ICMP echo request, id 21603, seq 4, length 64
13:20:39.295957 IP 202.128.xx.xx > 66.160.140.241: ICMP echo request, id 21603, seq 5, length 64
13:20:40.297627 IP 202.128.xx.xx > 66.160.140.241: ICMP echo request, id 21603, seq 6, length 64
13:20:41.298527 IP 202.128.xx.xx > 66.160.140.241: ICMP echo request, id 21603, seq 7, length 64
13:20:42.301971 IP 202.128.xx.xx > 66.160.140.241: ICMP echo request, id 21603, seq 8, length 64
13:20:43.307694 IP 202.128.xx.xx > 66.160.140.241: ICMP echo request, id 21603, seq 9, length 64

I can ping things from the VyOS router and can ping from outside to the 72.52.106.135 address. I’m going spare trying to figure out what I’m doing wrong and why I can’t ping anything on the 66.160.140.240/31 subnet.

Any advice?

2

Traffic from “the Internet” coming in via eth1 is always going to route out eth0 - that’s your default route.

Monitor eth0 while your ping is running - is traffic leaving there? If so, almost certainly your ISP has uRPF on (as an ISP this is something we apply to all subscribers) so your ISP will be going “source IP 66.160.140.240 isn’t behind 72.52.106.135/31 so I’m going to drop that packet”

Please let us know what you see when you monitor eth0 doing your ping.

3

Thanks. I have already shared the output of monitor traffic interface eth0 above. I just filtered by host I was pinging from.

If I replace this VyOS box with pfSense and configure it the same way it works.

4

My apologies, I read that at least twice to confirm I’d seen eth1 but I’m obviously blind!

I take it 66.160.140.240/31 has been allocated to you and is routed to you via 72.52.106.135?

What do you see if you monitor eth1 then while pinging, does traffic route out to your host?

5

Yes, 66.160.140.240/28 is routed to 72.52.106.135. I have carved that up to use 66.160.140.240/31 as a p2p, but even if I changed the /31 to /28 I get the same result. Again, I can see ICMP request packets coming from the internet to eth0, just no replies.

When I monitor eth1 whilst pinging from host 202.128.xx.xx (on the internet) I see nothing. So the VyOS router is deciding not to accept that packet to either eth1 if pinging 66.160.140.240 or forward the packet if pinging 66.160.140.241.

When I ping from 66.160.140.241 (the downstream device) to VyOS on 66.160.140.240 (eth1) I can see request/reply on eth1. When I try to ping 1.1.1.1 from 66.160.140.241, I can see icmp request on eth1 and nothing on eth0.

This is such a basic setup. No firewall configured, no NAT rules. I have even reinstalled VyOS and that hasn’t solved. I am now going to install a 1.4 version and see if I hit the same problem. Again, when I replace VyOS with pfSense and configure it the same way, everything works fine.

6

Yes I agree this is a very very simple setup and I can’t fathom why it’s not working. Can you share the full config?

Does “dmesg” have any output of interest?

7

I have attached the full config.

show_configuration.txt (1.5 KB)

The only thing I see in dmesg is my adapters entering/leaving promiscuous mode.

[ 1097.023039] virtio_net virtio0 eth0: entered promiscuous mode
[ 1198.442990] virtio_net virtio0 eth0: left promiscuous mode
[ 1557.978822] virtio_net virtio0 eth0: entered promiscuous mode
[ 1561.151312] virtio_net virtio0 eth0: left promiscuous mode
[ 1576.813271] virtio_net virtio0 eth0: entered promiscuous mode
[ 1579.711459] virtio_net virtio0 eth0: left promiscuous mode
[ 1598.348518] virtio_net virtio0 eth0: entered promiscuous mode
[ 1638.723879] virtio_net virtio0 eth0: left promiscuous mode
[ 1679.561331] virtio_net virtio0 eth0: entered promiscuous mode
[ 1692.376384] virtio_net virtio0 eth0: left promiscuous mode
[ 2536.946554] virtio_net virtio0 eth0: entered promiscuous mode
[ 2546.317608] virtio_net virtio0 eth0: left promiscuous mode
[ 2556.765003] virtio_net virtio0 eth0: entered promiscuous mode
[ 2562.070102] virtio_net virtio0 eth0: left promiscuous mode
[ 2564.880322] virtio_net virtio0 eth0: entered promiscuous mode
[ 2738.577560] virtio_net virtio0 eth0: left promiscuous mode
[29558.084053] virtio_net virtio1 eth1: entered promiscuous mode
[29563.631610] virtio_net virtio1 eth1: left promiscuous mode
[29579.283348] virtio_net virtio1 eth1: entered promiscuous mode
[30556.626790] virtio_net virtio1 eth1: left promiscuous mode

8

The only thing I can suggest is disabling all those offloads and see if it helps. What’s your hypervisor?

There must be some bug/issue with firewalling that’s biting you here. Can you try the latest rolling please?

9

Thanks. I removed the offloads and that didn’t make a difference. I am using Nutanix AHV as the hypervisor.

I am about to rebuild with 1.4.4 and see if it works with that. I will then rebuild with the latest rolling release and test again.

I will update this thread when I’m done. Appreciate you responding!

10

Please do update, something this simple is going to annoy me until I know what the solution is!!

11

I have performed a rebuild of the router on 1.4.4 and rolling release 2026.02.03-0027 and I get the same result. ICMP request coming into eth0, nothing seen on eth1. Packets are not being forwarded.

Was really hoping I could use VyOS everywhere in my network, but if it can’t get this basic routing right then it will be hard for me to convince my team to adopt it.

Appreciate your help.

12

Can you humour me and put these in:

set firewall global-options state-policy established action accept
set firewall global-options state-policy related action accept
set firewall global-options state-policy invalid action drop

You shouldn’t need those but I’m fast running out of ideas!!

13

Appreciate the suggestion, and glad I’m not the only one going insane!

I’ve applied those firewall configs as you’ve suggested and it didn’t change anything. When I monitor eth0 I see the ICMP request come in, when I monitor eth1 I see nothing.

14

Can you provide the output of nft list ruleset (might need to preface it with sudo)

I’m really at a loss though - it’s the most basic of setups and it should work.

sudo cat /proc/sys/net/ipv4/ip_forward returns “1” right??

15

Thanks for replying. I’ve attached the output of nft list ruleset.

And yes, the value of /proc/sys/net/ipv4/ip_forward is 1.

nft_list_ruleset.txt (7.7 KB)

16

Perhaps already answered but does it work when you from your VyOS ping:

  • 202.128.xx.xx ?
  • 72.52.106.134 ?
  • 66.160.140.241 ?

Also “did you try to turn it off and on again” aka reboot the VyOS ?

And your ping (when pinging from 202.128.x.x) is to reach the downlink interface from the uplink. Does it work when you ping the uplink interface instead that is 72.52.106.135?

Im thinking if the downlink interface somehow is broken in your hypervisor or incorrectly configured or something?

So that would explain why you dont get any reply from 66.160.140.241 while not getting reply from 66.160.140.240 could be because you ping from the uplink and not the downlink.

As I recall it there is some kernel flag one need to set to allow for replies from other interfaces within a box. Otherwise if you set which IP your SSH-server should listen to then anyone would still be able to get a SSH login to your box no matter if it listens to 0.0.0.0 or < mgmt-ip >. That is something along with packets ending up at “input” chain will only be able to reply through the “output” chain of the same interface. While for ip routing they end up at the “forward” chain and is not affected by this filtering.

17

And whats the output of these flags in your VyOS?

sysctl net.ipv4.conf.all.arp_filter
sysctl net.ipv4.conf.all.rp_filter

There might be interface specific aswell like replace all with eth0 and eth1. I dunno which have presence in Linux if the global one (all) wins over the local settings (eth0 and eth1) or not.

18

Hmm, Im not able to reproduce this on vyos-2025.11-generic-amd64.iso.

In my case I setup eth0 as uplink with default route pointing to upstream device and eth1 as downlink with my client connected to eth1. I am however using /24 instead of /31 for both interfaces.

I was both able to ping beyond my VyOS (that is what is setup as default gateway at eth0) along with the eth0 interface itself even if my client is located through eth1.

Similar when I put my client at eth0 then I can ping both the IP-addresses of eth0 and eth1.

Regarding rp_filter and arp_filter the rp_filter is set to 0 for all, default, eth0 and eth1.

While arp_filter is set to 0 except for eth0 and eth1 where its set to 1.

I might add that I tested a livebooted vyos-2025.11-generic-amd64.iso where I just changed the keyboard-layout, static IPv4 of eth0 and eth1 and pointed default route to upstream device reachable through eth0.

As in I didnt disable any default offloading and such.

Using Proxmox 9.x with virtio interfaces.

19

Can you also check/share your ARP tables - is everything (i.e. the client) there?

20

Output from “show interfaces” might be handy to verify that the mac-addresses used by hw-id in VyOS matches the mac-addresses that should exist for this client (is the correct ethX mapped to the correct mac-address?) along with if the interfaces are up or not (S/L column as I recall it).