Bug 231598 - SNAT problems with 2.6.19 (and xen?)
Summary: SNAT problems with 2.6.19 (and xen?)
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 6
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
URL:
Whiteboard:
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:
Environment:
Last Closed: 2008-02-08 04:27:28 UTC
Type: ---
Embargoed:


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:
http://lists.xensource.com/archives/html/xen-users/2006-09/msg00925.html )
The domU hosts get an internal IP address (say, 192.168.0.x), dom0 has a virtual
veth0 with IP address 192.168.0.1 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:
Always

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
10.0.0.1 in the file)
2. On dom0:
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j SNAT --to <eth0 address of dom0>
echo "1" > /proc/sys/net/ipv4/ip_forward
3. On domU
wget http://www.google.com 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
than 10.0.0.1


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 http://193.239.211.46
--12:08:09--  http://193.239.211.46/
Connecting to 193.239.211.46:80... connected.
HTTP request sent, awaiting response... No data received.
Retrying.


Thanks for your help and kind regards,

Bruno

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

Bruno


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)

Hello,

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

http://fedoraproject.org/wiki/KernelBugTriage

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

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.