Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 231598 - SNAT problems with 2.6.19 (and xen?)
Summary: SNAT problems with 2.6.19 (and xen?)
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 6
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
Depends On:
Blocks: 427887
TreeView+ depends on / blocked
Reported: 2007-03-09 11:15 UTC by Bruno De Wolf
Modified: 2008-02-08 04:27 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-02-08 04:27:28 UTC

Attachments (Terms of Use)

Description Bruno De Wolf 2007-03-09 11:15:52 UTC
Description of problem:
I have the impression that iptables SNAT does not work correctly in 2.6.19 kernels. 

Our context is that we are running xen with the virtual domains running in a
private network (as described here: )
The domU hosts get an internal IP address (say, 192.168.0.x), dom0 has a virtual
veth0 with IP address acting as default gateway on the domU's. It's
the idea that ip forwording and SNAT on dom0 should give the right access to the
domU's. This approach seems to work on 2.6.18 kernels, but not on 2.6.19

Version-Release number of selected component (if applicable):
Kernels tested and ok: 
- kenel-xen-2.6.18-1.2869 (x86_64)
- kernel-xen-2.6.18-1.2849 (i386)
Kernels test and NOT ok:
- kernel-xen-2.6.19-1.2911 (x86_64)
- kernel-xen-2.6.19-1.2911.6.5 (i386)

How reproducible:

Steps to Reproduce:
1. Start xen with '(network-script network-private)' in xend-config.sxp
(network-private script is coming from above link - modify the veth0 address to in the file)
2. On dom0:
iptables -t nat -A POSTROUTING -s -j SNAT --to <eth0 address of dom0>
echo "1" > /proc/sys/net/ipv4/ip_forward
3. On domU
wget or whatever
Actual results:
Approach works on 2.6.18, no (or sometimes very slow) connectivity in domU if
dom0 runs 2.6.19. In fact, executing traceroute on domU shows nothing further

Expected results:
normal working wget, ftp, ssh...

Additional info:
- This might be completley independent of xen and a pure iptables problem.
However, I don't have the equipment to test this.
- Executing an ftp session on domU to an external system, shows the greeting
message, but not the login. Which makes me think that packets are going out
correctly, but not coming back, or maybe only the first package manages to get
back. It also reinforces me of my idea that this is likely not a xen issue.
- This stuff is a bit at the edge of my knowledge, so please give some
explanation if you want me to execute some tests.
- And here's a wget output:
[root@ninja ~]# wget
Connecting to connected.
HTTP request sent, awaiting response... No data received.

Thanks for your help and kind regards,


Comment 1 Bruno De Wolf 2007-03-09 11:18:09 UTC
Woops, the line 'modify the veth0 address to in the file' in 'how to
reproduce' shouldn't really be there.


Comment 2 Jon Stanley 2008-01-08 01:49:29 UTC
(This is a mass-update to all current FC6 kernel bugs in NEW state)


I'm reviewing this bug list as part of the kernel bug triage project, an attempt
to isolate current bugs in the Fedora kernel.

I am CC'ing myself to this bug, however this version of Fedora is no longer

Please attempt to reproduce this bug with a current version of Fedora (presently
Fedora 8). If the bug no longer exists, please close the bug or I'll do so in a
few days if there is no further information lodged.

Thanks for using Fedora!

Comment 3 Jon Stanley 2008-02-08 04:27:28 UTC
Per the previous comment in this bug, I am closing it as INSUFFICIENT_DATA,
since no information has been lodged for over 30 days.

Please re-open this bug or file a new one if you can provide the requested data,
and thanks for filing the original report!

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