Packets "disappearing" in VNET with IPfire as router

#1

Hi everyone,
(go to 5th comment for updated case)

I’m with a strange problem. Using VNET (802.1q), and using IPfire as router, the “client” can’t receive packages from out of Vnet; the packages outing of IPfire interface, but “disappearing” before enter in the brigde of host. But connection between IPFire and client is OK, they responding ping. The two machines are in the same host, and all firewall rules are “ACCEPT”.
Below is detailed explanation of environment:

VNET onebr58 ================== VNet external
______________________________ | __________________

Client <---------------------------------> IPFire <------------------- Internet
VMid: 309 _________________ Vmid: 317
192.168.235.4 - - - - - - 192.168.235.3 | xxx.xxx.40.133
_______________________ _green0 | red0

Client:

# ping 192.168.235.3
PING 192.168.235.3 (192.168.235.3) 56(84) bytes of data.
64 bytes from 192.168.235.3: icmp_seq=1 ttl=64 time=1.40 ms
64 bytes from 192.168.235.3: icmp_seq=2 ttl=64 time=0.731 ms
64 bytes from 192.168.235.3: icmp_seq=3 ttl=64 time=0.697 ms
64 bytes from 192.168.235.3: icmp_seq=4 ttl=64 time=0.609 ms

# ping 8.8.4.4
PING 8.8.4.4 (8.8.4.4) 56(84) bytes of data.
(no returns)

IPFire:

# tcpdump -i red0 -nn icmp
09:01:27.713865 IP xxx.xxx.40.133 > 8.8.4.4: ICMP echo request, id 14361, seq 2232, length 64
09:01:27.715985 IP 8.8.4.4 > xxx.xxx.40.133: ICMP echo reply, id 14361, seq 2232, length 64

# tcpdump -i green0 -nn icmp
09:02:08.713235 IP 192.168.235.4 > 8.8.4.4: ICMP echo request, id 14361, seq 2273, length 64
09:02:08.715755 IP 8.8.4.4 > 192.168.235.4: ICMP echo reply, id 14361, seq 2273, length 64

In physical host:

# tcpdump -i onebr58 -nn
09:05:16.711122 IP 192.168.235.4 > 8.8.4.4: ICMP echo request, id 14361, seq 2461, length 64
09:05:17.711114 IP 192.168.235.4 > 8.8.4.4: ICMP echo request, id 14361, seq 2462, length 64
09:05:18.711079 IP 192.168.235.4 > 8.8.4.4: ICMP echo request, id 14361, seq 2463, length 64

In IPtables of host is:
Chain one-309-0-i (1 references)
target prot opt source destination
ACCEPT all – 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
RETURN all – 0.0.0.0/0 0.0.0.0/0
DROP all – 0.0.0.0/0 0.0.0.0/0

Chain one-309-0-o (1 references)
target prot opt source destination
ACCEPT all – 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
RETURN all – 0.0.0.0/0 0.0.0.0/0
DROP all – 0.0.0.0/0 0.0.0.0/0

Chain one-317-1-i (1 references)
target prot opt source destination
ACCEPT all – 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
RETURN all – 0.0.0.0/0 0.0.0.0/0
DROP all – 0.0.0.0/0 0.0.0.0/0

Chain one-317-1-o (1 references)
target prot opt source destination
ACCEPT all – 0.0.0.0/0 0.0.0.0/0
ACCEPT all – 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
RETURN all – 0.0.0.0/0 0.0.0.0/0
DROP all – 0.0.0.0/0 0.0.0.0/0

Anyone have any test or idea of how to debug or resolve this?

0 Likes

(Moreno) #2

Maybe a routing / NAT problem, just my 2 cents…

0 Likes

#3

I found a partial solution: I noticed that if I create a vnet as “ethernet” (without IP address) and configure IPs manually (tha same IPs configurations), works fine.

Where I`m wrong?

0 Likes

#4

Update: I noticed too that the problem occurs in cases where I need put manually the IP address. (ex: IPfire, pfsense, etc). Even putting the same IP that is attribute, the network not working.

0 Likes

#5

I found the problem. In VM deployment, Opennebula use “filterref”* in interface creation. In consequence, a filter is applied and just packenges that corresponds with source IP address of interface can pass. As VM are routing package from internet, source IP is different of interface IP address.
I tried create a VM as router, but the problem persist. How to fix this?

*https://libvirt.org/formatnwfilter.html

0 Likes