[SOLVED] VMs can't reach the gateway

P

pludikovsky

Member
Nov 8, 2022
4
1
8
Setup:
  • Network: 10.x.y.0/22
  • Gateway & DNS: 10.x.y.1
  • Proxmox: 10.x.y.241/22
    • vmbr0 contains bond0, which bonds 4 physical interfaces
  • VM: 10.x.(y+1).1/22
  • Firewall is off both on Proxmox and the VM

Situation:
  • I can ping the gateway from Proxmox and vice versa
  • I can ping Proxmox from the VM and vice versa
  • I can ping the VM from the gateway
  • I can't ping the gateway from the VM

Anyone got an idea what I missed? During the setup the VMs had a random IP via DHCP and everything worked as intended, after the setup this was changed to a fixed IP, still assigned via DHCP.
 
I think it would make things easier if you showed the values of 'x' and 'y', as the problem could be that you're assigning addresses which are not valid for the /22 netmask (normally it's 10.x.y.z/8 anyway).

Are the VMs running Linux? what does "ip route" show?

If the gateway is not in the assigned subnet (which depends on your values of 'x' and 'y') you may have to tell the VM that the gateway is on the link ("GatewayOnLink" if using systemd-networkd).
 
@reinob Network is 10.9.8.0/22, so 10.9.8.1-10.9.11.254. Gateway is 10.9.8.1, Proxmox is 10.9.8.241, VM is 10.9.9.1. And like I said, the gateway can ping the VM, it just doesn't work the other way around, but the gateway is pingable from other (non-VM) nodes.

@MarkusKo Just because the 10./8 network can be that size nothing requires it to be that size. It just means that range is reserved for private use.
 
the only thing i could think of is a subnet mask mismatch ...
double check the subnet mask on your vm and the dhcp server config

as you already stated in your 10.9.8.0/22 network it should be 255.255.252.0
 
@pludikovsky: thanks for the clarification!

What does "ip route" show?
how is networking configured in the VM? (ifupdown, systemd-networkd, etc.)
 
@reinob
Code: 
# ip route
default via 10.9.8.1 dev ens18
10.9.8.0/22 dev ens18 proto kernel scope link src 10.9.9.1

Configuration is via ifupdown (default Debian):
Code: 
iface ens18 inet dhcp
 
I found the issue, completely my fault. I didn't think of the fact that we've had the VPN configured on the 10.9.9.0/24 range. Of course then the routing gets all fucked up…
 
  • Like
Reactions: reinob
i would suggest using only /24 if you can, makes things easier to remember and to handle.
don't see many reasons to use bigger subnets as you always want to segement your network with vlans / subnets anyway.
 
You must log in or register to reply here.
Top Bottom