Re: Xen, ebtables and iptables problem

I have assigned an IP address to the bridge and configured the iptables
to dnat the packets. 

iptables -t nat -A PREROUTING -i xenbr0 -s 192.168.1.3 -p tcp --dport 80
-j DNAT --to bridge_ip:3128


Now I am seeing something really strange. I've captured the packets at
eth1 and the first four tcp packets are correct but the 5th one is
coming with the source port changed to 1!! That is:

Packet nr       dst ip      dst port        src ip         src port
1 [SYN]         google        80          192.168.1.3      1111
2 [SYN/ACK]  192.168.1.3    1111            google           80    
3 [ACK]         google        80          192.168.1.3      1111
4 HTTP GET      google        80          192.168.1.3      1111
5 [ACK]      192.168.1.3       1            google         1111
6 [RST]         google      1111		192.168.1.3
1


I also captured the packets at xenbr0 and packet 6 is coming from port
80 as supposed to be, however it is directed to 192.168.1.3 is this
correct?

Have you seen this before?

Regards,
Pablo

>-----Original Message-----
>From: ebtables-user-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
[mailto:ebtables-user-
>[email protected]] On Behalf Of Grant Taylor
>Sent: Friday, September 28, 2007 1:01 PM
>To: Mail List - EBTables
>Subject: Re: [Ebtables-user] Xen, ebtables and iptables problem
>
>On 09/28/07 09:54, Passera, Pablo R wrote:
>> You were right; the problem was with the interface name. The iptables
>> rule is matching when I put the interface as xenbr0 (which is the
>> bridge).
>>
>> iptables -t nat -A PREROUTING -i xenbr0 -s 192.168.1.3 -p tcp --dport
>> 80 -j REDIRECT --to-port 3128
>
>Good.  I'm glad that it is working.
>
>> But now I have another problem, I cannot see the packet being
>> redirected to 127.0.0.1. Actually, it is like the packet is lost.
>> Maybe this is because xen is handling the interfaces in some strange
>> way.
>
>Eh, I'm not sure that Xen is causing your problem.  What I am sure of
is
>that redirecting any thing in to or out of the loop back interface is
>problematic at best.  That is because, as I understand it, the kernel
>protects loop back and only allows local traffic to communicate with
it.
>  In this case, I think you will have more luck using dummy0 than loop
>back for redirecting traffic in.
>
>> Anyway, I will try to do the same thing but using DNAT and
redirecting
>> the packet to 192.168.1.2
>
>I think you will have more luck doing that.
>
>It looks like you have your 192.168.1.2 IP address bound to eth0.  I
>have had considerable luck binding IP addresses directly to the bridge
>interface.  So you may want to consider doing such.  Just an idea.
>
>
>
>Grant. . . .
>
>-----------------------------------------------------------------------
--
>This SF.net email is sponsored by: Microsoft
>Defy all challenges. Microsoft(R) Visual Studio 2005.
>http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>_______________________________________________
>Ebtables-user mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/ebtables-user

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/