Bug 741929 - RFE: network: allow multiple <forward> specifications
Summary: RFE: network: allow multiple <forward> specifications
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-28 13:54 UTC by Guilhem Lettron
Modified: 2020-11-03 16:31 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-03 16:31:22 UTC
Embargoed:


Attachments (Terms of Use)

Description Guilhem Lettron 2011-09-28 13:54:16 UTC
Description of problem:
In network, we can't use multiple forward type (for example nat + routed).

Version-Release number of selected component (if applicable):


How reproducible:

this configuration doesn't work :

<network>
        <name>default</name>
        <bridge name="virb0" stp="on" delay="5"/>
        <forward mode="nat" dev="eth0"/>
        <forward mode="route" dev="tun1"/>
        <ip address="192.168.2.1" netmask="255.255.255.0">
        <dhcp>
            <range start="192.168.2.10" end="192.168.2.250" />
        </dhcp>
        </ip>
</network>
  
Actual results:
Parse false

Expected results:
iptables rules must be like this :

-A FORWARD -d 192.168.2.0/24 -i eth0 -o virb0 -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD -s 192.168.2.0/24 -i virb0 -o eth0 -j ACCEPT

-A FORWARD -s 192.168.2.0/24 -i virb0 -o tun1 -j ACCEPT 
-A FORWARD -d 192.168.2.0/24 -i tun1 -o virb0 -j ACCEPT

-A FORWARD -i tinc -o tinc -j ACCEPT

-A FORWARD -o tinc -j REJECT --reject-with icmp-port-unreachable 
-A FORWARD -i tinc -j REJECT --reject-with icmp-port-unreachable

Additional info:

Comment 1 Cole Robinson 2016-03-23 13:52:01 UTC
laine, is this something current libvirt provides? if not is it a sensible request or something that can/should be achieved in some other way?

Comment 2 Laine Stump 2016-03-23 18:34:56 UTC
No, libvirt can't currently do that. It's an interesting idea though (I'm not sure why I don't remember seeing this BZ before - was I only added to the Cc when you set needinfo for me?)

At least as important as any change to the FORWARD table is that the MASQUERADE table will need to be modified - there will need to be one for each forward interface that's in NAT mode and it will need to include the destinationg interface (rather than just a negative of the IP address, as is currently the case).

Comment 3 Daniel Berrangé 2020-11-03 16:31:22 UTC
Thank you for reporting this issue to the libvirt project. Unfortunately we have been unable to resolve this issue due to insufficient maintainer capacity and it will now be closed. This is not a reflection on the possible validity of the issue, merely the lack of resources to investigate and address it, for which we apologise. If you none the less feel the issue is still important, you may choose to report it again at the new project issue tracker https://gitlab.com/libvirt/libvirt/-/issues The project also welcomes contribution from anyone who believes they can provide a solution.


Note You need to log in before you can comment on or make changes to this bug.