Bug 508339

Summary: traceroute from guest to host in NAT mode shows errors
Product: Red Hat Enterprise Linux 5 Reporter: Paolo Bonzini <pbonzini>
Component: libvirtAssignee: Laine Stump <laine>
Status: CLOSED WONTFIX QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: low    
Version: 5.4CC: dallan, hbrock, jdenemar, jialiu, pveiga, veillard, virt-maint, xen-maint, ykaul, yoyzhang
Target Milestone: rcKeywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-10-17 15:20:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
vm xml configuration
none
wireshark capture file none

Description Paolo Bonzini 2009-06-26 16:35:11 UTC 
Description of problem:
From a KVM guest, I can access the host via the 192.168.122.1 address, but not with its "external" address.

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

How reproducible:
Try traceroute from the guest to the host

Steps to Reproduce:
1. Start a KVM guest without PV-on-HVM drivers (RHEL-4 in my case).
2. Do hostname on the host
3. On the guest, start a traceroute on the output of the hostname command

Actual results:
traceroute to dhcp-lab-204.englab.brq.redhat.com (10.34.33.204), 30 hops max, 46 byte packets
 1  dhcp-lab-204.englab.brq.redhat.com (10.34.33.204)  0.181 ms !<10>  0.160 ms !<10>  0.151ms !<10>

Expected results:
This is the output of traceroute to a different machine than the host, in the same subnet.
traceroute to dhcp-lab-218.englab.brq.redhat.com (10.34.33.218), 30 hops max, 46 byte packets
 1  192.168.122.1 (192.168.122.1)  0.173 ms  0.150 ms  0.143 ms
 2  dhcp-lab-218.englab.brq.redhat.com (10.34.33.218)  0.270 ms  0.228 ms  0.231ms

Additional info:
Output of route on the guest:
192.168.122.0   *              255.255.255.0  U   0    0    0  eth0
169.254.0.0     *              255.255.0.0    U   0    0    0  eth0
default         192.168.122.1  0.0.0.0        UG  0    0    0  eth0

Output of route on the host:
192.168.122.0   *              255.255.255.0  U   0    0    0  virbr0
10.34.32.0      *              255.255.252.0  U   0    0    0  eth0
169.254.0.0     *              255.255.0.0    U   0    0    0  eth0
default         gw.enlab.brq.r 0.0.0.0        UG  0    0    0  eth0

Output of iptables-save on the host:
# Generated by iptables-save v1.3.5 on Fri Jun 26 18:15:45 2009
*nat
:PREROUTING ACCEPT [1280:180578]
:POSTROUTING ACCEPT [236:17652]
:OUTPUT ACCEPT [237:17803]
-A POSTROUTING -s 192.168.122.0/255.255.255.0 -d ! 192.168.122.0/255.255.255.0 -j MASQUERADE 
COMMIT
# Completed on Fri Jun 26 18:15:45 2009
# Generated by iptables-save v1.3.5 on Fri Jun 26 18:15:45 2009
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [9346:14778380]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT 
-A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT 
-A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT 
-A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT 
-A INPUT -j RH-Firewall-1-INPUT 
-A FORWARD -d 192.168.122.0/255.255.255.0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD -s 192.168.122.0/255.255.255.0 -i virbr0 -j ACCEPT 
-A FORWARD -i virbr0 -o virbr0 -j ACCEPT 
-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable 
-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable 
-A FORWARD -j RH-Firewall-1-INPUT 
-A RH-Firewall-1-INPUT -i lo -j ACCEPT 
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT 
-A RH-Firewall-1-INPUT -p esp -j ACCEPT 
-A RH-Firewall-1-INPUT -p ah -j ACCEPT 
-A RH-Firewall-1-INPUT -d 224.0.0.251 -p udp -m udp --dport 5353 -j ACCEPT 
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT 
-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2049 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited 
COMMIT
# Completed on Fri Jun 26 18:15:45 2009
Comment 1 Paolo Bonzini 2009-06-26 17:07:56 UTC 
changing component from kvm to libvirt.
Comment 2 Daniel Berrangé 2009-06-26 17:44:01 UTC 
Is 'ip_forward' enabled ?
Comment 3 Paolo Bonzini 2009-06-26 18:06:38 UTC 
I cannot check until monday unless the weekend is very rainy, but in case it helps it is just connecting to the host that has a problem.  Any other IP address is routed properly.
Comment 4 Paolo Bonzini 2009-06-26 19:54:25 UTC 
Yes, ip_forward enabled.  Note that everything works, it's just the ICMP error that puzzled me.
Comment 5 Paolo Bonzini 2009-06-26 20:09:43 UTC 
Created attachment 349601 [details]
vm xml configuration

I attach the XML file from which I created the vm.

The network configuration can be found in https://bugzilla.redhat.com/show_bug.cgi?id=508335#c3
Comment 13 Jiri Denemark 2010-09-10 09:18:42 UTC 
Paolo is willing to check the status of this bug with the rebased libvirt; setting needinfo for him
Comment 14 Paolo Bonzini 2010-09-17 16:09:29 UTC 
Still reproducible with the rebased libvirt: the UDP packets sent by traceroute are rejected with ICMP "Host administratively prohibited".

I'll attach a trace file.
Comment 15 Paolo Bonzini 2010-09-17 16:10:28 UTC 
Created attachment 448044 [details]
wireshark capture file
Comment 17 RHEL Program Management 2010-10-13 15:05:27 UTC 
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.
Comment 18 Dave Allan 2010-10-13 18:39:56 UTC 
Closed in error; reopening and moving to 5.7.
Comment 20 RHEL Program Management 2011-01-11 20:26:21 UTC 
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 21 RHEL Program Management 2011-01-11 22:59:07 UTC 
This request was erroneously denied for the current release of
Red Hat Enterprise Linux.  The error has been fixed and this
request has been re-proposed for the current release.
Comment 25 Dave Allan 2011-10-17 15:20:43 UTC 
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.