No external connectivity from virtual machines

Community Support
1

Hi everyione I have a strange network issue that i would like some help please to sort it out please. I have 3 virtual networks configured:

1 has public internet access 10.1.3.0/24
2 internal network 192.168.122.0/24 and 192.168.121.0/24

A virtual router (Untangle)is configured with 3 interfaces for one of each networks above as shown below:

WAN - 10.1.3.12/24
LAN1 - 192.168.121.14/24
LAN2 - 192.168.122.10/24

from the router i can ping machines on LAN1, LAN2 and the internet (i.e. over the WAN interface).

Neither from LAN1 nor LAN2 can I ping anything apart from the default gateway which is the corresponding LAN interface on the router. First thing that came to mind was NAT but as you can see below
these are 2 tcpdumps for the WAN and LAN2 interfaces during a ping to 8.8.8.8

–> WAN

18:12:42.506156 IP 10.1.3.12 > 8.8.8.8: ICMP echo request, id 2385, seq 300, length 64
18:12:42.549902 IP 8.8.8.8 > 10.1.3.12: ICMP echo reply, id 2385, seq 300, length 64
18:12:42.680640 IP 10.1.3.12.123 > 193.47.166.29.123: NTPv4, Client, length 48
18:12:42.820302 IP 193.47.166.29.123 > 10.1.3.12.123: NTPv4, Server, length 48
18:12:43.506195 IP 10.1.3.12 > 8.8.8.8: ICMP echo request, id 2385, seq 301, length 64
18:12:43.549368 IP 8.8.8.8 > 10.1.3.12: ICMP echo reply, id 2385, seq 301, length 64
18:12:44.506167 IP 10.1.3.12 > 8.8.8.8: ICMP echo request, id 2385, seq 302, length 64
18:12:44.550348 IP 8.8.8.8 > 10.1.3.12: ICMP echo reply, id 2385, seq 302, length 64
18:12:45.506146 IP 10.1.3.12 > 8.8.8.8: ICMP echo request, id 2385, seq 303, length 64
18:12:45.552889 IP 8.8.8.8 > 10.1.3.12: ICMP echo reply, id 2385, seq 303, length 64

–> LAN2

18:15:31.503117 IP 192.168.122.41 > 8.8.8.8: ICMP echo request, id 2385, seq 469, length 64
18:15:31.553273 IP 8.8.8.8 > 192.168.122.41: ICMP echo reply, id 2385, seq 469, length 64
18:15:32.503223 IP 192.168.122.41 > 8.8.8.8: ICMP echo request, id 2385, seq 470, length 64
18:15:32.548841 IP 8.8.8.8 > 192.168.122.41: ICMP echo reply, id 2385, seq 470, length 64
18:15:33.503100 IP 192.168.122.41 > 8.8.8.8: ICMP echo request, id 2385, seq 471, length 64
18:15:33.546207 IP 8.8.8.8 > 192.168.122.41: ICMP echo reply, id 2385, seq 471, length 64
18:15:34.503129 IP 192.168.122.41 > 8.8.8.8: ICMP echo request, id 2385, seq 472, length 64
18:15:34.546489 IP 8.8.8.8 > 192.168.122.41: ICMP echo reply, id 2385, seq 472, length 64

–> CentOS 7 VM tcpdump on eth0

image
image.png809×274 18.1 KB

for some strange reason the packet is not reaching the VM interface but it looks like the virtual router is sending the packets to the VM. I am not using any contextualization and all the seetings in both the instances and the virtual routers are being done manually.

Thanks in advance

2

Ok so I might have identified where this is coming from (ebtables)… I spent a whole day yesterday doing packet traces and also reverted to VyOS from Untangle (although that would not have been the issue but I wanted to rule it out too). Traffic was following this path for a ping from VM1 (192.168.121.16) in LAN1 to 8.8.8.8:

VM1-192.168.121.16 --> VR-LAN1-GW-192.168.121.14 --> NAT --> 10.1.3.12 --> (INTERNET) --> 8.8.8.8 and the packet arrives to its destination, now when the packet is coming back it is “following the same path” except for the last part only, which is VR-LAN1-GW-192.168.121.14 --> VM1-192.168.121.16. The echo reply does not go out of the VR interface or it is going out of the VR but dropped.

No matter if ebtables is up or down on startup when the host which hosts the VR VM is up a “systemctl stop ebtables” in case it is started or a restart in case it is stopped will let the packets flow. The issue seems to be coming from the below:
https://docs.opennebula.org/5.4/deployment/open_cloud_networking_setup/bridged.html#ebtables-vlan-mode-default-rules

Drop packets that don’t match the network’s MAC Address

-s ! <mac_address>/ff:ff:ff:ff:ff:0 -o <tap_device> -j DROP

Prevent MAC spoofing

-s ! <mac_address> -i <tap_device> -j DROP

If I could read the above correctly according to an overview guide here http://www.dilnetpc.com/ebtables-cmd-overview.pdf the first line means that the packet will be dropped, but what I cannot understand is that the packet in fact originated from this network so why it is dropped.:

-s, --source[!]address[/mask] The source mac address
A “!” option before the specification inverts the test for that specification.
-o, --out-interface[!]name The interface via which a frame is going to be sent.
-j, --jump The target of the rule.

Can anyone tell me:
1-How to disable ebtables completely since I am not using it?
2-What is in fact happening?
3-Why is ebtables interfering when I am using 802.1Q VLAN Networks?

Thanks in advance for nay feedback