networking question
hi, I have an issue with one host at a customer's site. I think this cannot work, but I would like to ask you just in case I am confused. host: eno1: 172.20.10.x/24 management interface gw 172.20.10.254 bridge-service: 0.0.0.0/24 tun0: openvpn tunnel to external data center internal-bridge: x.x.x.x/28 ; routed subnet that goes to openvpn tun0 on vm: eth0: x.x.x.x/28 on internal-bridge (default gw) eth1: 172.20.10.x/24 bridge-service gw 172.20.10.254 (same as eno1) Connectivity to and from openvpn (from and to datacenter) is perfect. All vms are directly reachable from our management services, no natting.
From hypervisor I can ping the gw, from vm I cannot ping 172.20.10.254.
My gut feeling is that this cannot work because traffic for the hypervisor for subnet 172.20.10.x/24 flows through eno1, but for vm through the bridge-loggin interface. So that cannot work. Should we just ask the customer to give us different subnets for the host and the vm? TIA. -- regards, Natxo
On Thu, Feb 24, 2022 at 07:07:18PM +0100, Natxo Asenjo wrote:
hi,
I have an issue with one host at a customer's site. I think this cannot work, but I would like to ask you just in case I am confused.
host: eno1: 172.20.10.x/24 management interface gw 172.20.10.254 bridge-service: 0.0.0.0/24 tun0: openvpn tunnel to external data center internal-bridge: x.x.x.x/28 ; routed subnet that goes to openvpn tun0
on vm: eth0: x.x.x.x/28 on internal-bridge (default gw) eth1: 172.20.10.x/24 bridge-service gw 172.20.10.254 (same as eno1)
Connectivity to and from openvpn (from and to datacenter) is perfect. All vms are directly reachable from our management services, no natting.
From hypervisor I can ping the gw, from vm I cannot ping 172.20.10.254.
My gut feeling is that this cannot work because traffic for the hypervisor for subnet 172.20.10.x/24 flows through eno1, but for vm through the bridge-loggin interface. So that cannot work.
I am not sure, but I would try to see where the packets are really going through by using wireshark/tshark or tcpdump. The only thing that I can come up on the spot is that it is trying to go through different interface at some point due to reverse path filtering, settings for that are in /proc/sys/net/ipv4/conf/*/rp_filter, it might be routed elsewhere anywhere along the way. But it is hard to say without knowing how all the networks are connected. Maybe I'm just bad at understanding your situation, for me it is usually better to see this stuff happen in wireshark. But I figured I at least let know know one idea which we had an issue before as well. Hope that helps, Martin
Should we just ask the customer to give us different subnets for the host and the vm?
TIA. -- regards, Natxo
On 2/25/22 11:05 AM, Martin Kletzander wrote:
On Thu, Feb 24, 2022 at 07:07:18PM +0100, Natxo Asenjo wrote:
hi,
I have an issue with one host at a customer's site. I think this cannot work, but I would like to ask you just in case I am confused.
host: eno1: 172.20.10.x/24 management interface gw 172.20.10.254 bridge-service: 0.0.0.0/24
I may be misunderstanding this "freehand" description of your setup, but it sounds like you have a Linux host bridge device that is attached to eno1 and to a VM (via a tap device), and that the bridge device has no IP address, but the host's ethernet device *does* have an IP address configured. I haven't ever tried the setup this way, but I do know that normally you should have *no IP* on the ethernet device, and an IP on the bridge device (every set of instructions I've ever seen for adding a bridge to an ethernet have included the step of "move the ethernet IP config over to the bridge device config"). If the config actually does have IP address on the ethernet but not on the bridge, try swapping that.
tun0: openvpn tunnel to external data center internal-bridge: x.x.x.x/28 ; routed subnet that goes to openvpn tun0
on vm: eth0: x.x.x.x/28 on internal-bridge (default gw) eth1: 172.20.10.x/24 bridge-service gw 172.20.10.254 (same as eno1)
Connectivity to and from openvpn (from and to datacenter) is perfect. All vms are directly reachable from our management services, no natting.
From hypervisor I can ping the gw, from vm I cannot ping 172.20.10.254.
My gut feeling is that this cannot work because traffic for the hypervisor for subnet 172.20.10.x/24 flows through eno1, but for vm through the bridge-loggin interface. So that cannot work.
I am not sure, but I would try to see where the packets are really going through by using wireshark/tshark or tcpdump.
The only thing that I can come up on the spot is that it is trying to go through different interface at some point due to reverse path filtering, settings for that are in /proc/sys/net/ipv4/conf/*/rp_filter, it might be routed elsewhere anywhere along the way. But it is hard to say without knowing how all the networks are connected. Maybe I'm just bad at understanding your situation, for me it is usually better to see this stuff happen in wireshark. But I figured I at least let know know one idea which we had an issue before as well.
Hope that helps, Martin
Should we just ask the customer to give us different subnets for the host and the vm?
TIA. -- regards, Natxo
participants (3)
-
Laine Stump -
Martin Kletzander -
Natxo Asenjo