[Bug 1853489] Re: Ignoring the default NAT when using the virtio adapter

2020-02-16 Thread Launchpad Bug Tracker
[Expired for libvirt (Ubuntu) because there has been no activity for 60 days.] ** Changed in: libvirt (Ubuntu) Status: Incomplete => Expired -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1853489] Re: Ignoring the default NAT when using the virtio adapter

2019-12-18 Thread The Darkness
I was able to recreate the topology on my home machine and was able to reproduce the problem. I will make more tests and report upstream soon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1853489

Re: [Bug 1853489] Re: Ignoring the default NAT when using the virtio adapter

2019-11-25 Thread Christian Ehrhardt 
> I will recreate this scenario on my home computer so i could have more flexibility on making tests. Sounds great, recreating it also means you might end up with a set of configs/commands anyone can use to recreate the case on a system from scratch. Reproducibility will help on this already well

[Bug 1853489] Re: Ignoring the default NAT when using the virtio adapter

2019-11-25 Thread The Darkness
I will recreate this scenario on my home computer so i could have more flexibility on making tests. I am sick and will be off for this week. But i will return to this ASAP. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1853489] Re: Ignoring the default NAT when using the virtio adapter

2019-11-25 Thread Christian Ehrhardt 
Maybe it fast-pathes around something when both are virtio. But you said you set driver=qemu and it still was broken with virtio, I didn't expect that. I have given it a few tries with a similar setup among a few VMs but haven't seen the issue myself. You probably want to report that upstream

[Bug 1853489] Re: Ignoring the default NAT when using the virtio adapter

2019-11-22 Thread The Darkness
I found that the problem only happens when the "virtio" device model is used in both pfSense internal and UBUNTU interfaces. I tested all combinations and get the following results: pfSense default confinada UBUNTU result virtio virtio virtioERR virtio virtio rtl8139 OK

[Bug 1853489] Re: Ignoring the default NAT when using the virtio adapter

2019-11-22 Thread The Darkness
I made some more tests and found that ICMP packets are NAT'ed OK independent of the device model used. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1853489 Title: Ignoring the default NAT when

[Bug 1853489] Re: Ignoring the default NAT when using the virtio adapter

2019-11-22 Thread The Darkness
I tried with and without the driver option set to qemu and the problem continues. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1853489 Title: Ignoring the default NAT when using the virtio adapter

[Bug 1853489] Re: Ignoring the default NAT when using the virtio adapter

2019-11-22 Thread Christian Ehrhardt 
Hi, interesting but nothing obvious comes directly to my mind. It is great that you identified that the device driver virtio/rtl8139 makes a difference. Lets start there to think about it. Traffic for rtl8139 will always go to host-userspace for device emulation and flow on from there. With

[Bug 1853489] Re: Ignoring the default NAT when using the virtio adapter

2019-11-21 Thread The Darkness
** Description changed: I am using libvirt with KVM on a UBUNTU 18.04.3 LTS I have the following topology inside libvirt/KVM The default virtual network with IP range 10.0.0.0/24 on virbr0 interface with IP 10.0.0.1 and DHCP enabled Another virtual network named "confinada" with IP