From: Francois Goudal <fg@satcom1.com>
To: netfilter@vger.kernel.org
Subject: NAT issue on a machine with both routing and bridging.
Date: Mon, 23 Jun 2008 16:22:21 +0200 [thread overview]
Message-ID: <485FB19D.9080908@satcom1.com> (raw)
Hi,
I need to make a quite special setup today and I'm running in trouble at
some point :
I'm running a software that does TCP PEP (Performance Enhancement Proxy)
on a machine with 2 NICs. Basically, this machine can be considered as a
bridge (except that all the TCP traffic is converted to another
protocol, but all the rest like UDP or ICMP is simply going through
without being altered)
My setup also requires a NAT gateway that does masquerading.
This works fine with 2 separate boxes, one doing the PEP, and the other
doing the NAT gateway, and one crossover cable between them.
But now I have a challenge : all this should fit in one single box.
So I decided to use virtual machines, like Xen (I tried UML as well, so
my problem is not related to Xen specifically).
Here is the basic test setup I have :
................ ................
. HOST A . . HOST D .
. 10.168.254.1 . . 172.16.33.10 .
................ ................
| |
| |
| |
| eth1 eth0 |
.....................................................................
. |0.0.0.0 0.0.0.0 | .
. |__________________________________ ________________| .
. | | .
............................ |_ br0 | .
. eth0 . vif1.0 | 0.0.0.0 | .
. XEN VM _________._________| | .
. HOST B | 0.0.0.0 . 0.0.0.0 | .
. | . |_ br2 .
. br0 _| . | 172.16.33.200 .
. 10.168.254.51 | eth1 . vif1.1 | ^ .
. |_________._________ | .
. 0.0.0.0 . 0.0.0.0 | | Routing .
............................ |_ br1 | + DNAT .
. | 10.168.254.250 <--' .
. | .
. HOST C .
.....................................................................
Hosts A and D are here to test the stuff in host C+B.
Host C is a Xen Host machine that contains one Xen VM for the PEP stuff
and which is responsible for the masquerading of packets.
Host B is a Virtual machine running on Host C which runs the PEP software.
As you can see, the 2 NICs of the Host C are running without an IP
address but they are up and they are part of bridge interfaces.
eth1 is bridged together with vif1.0 (which corresponds to eth0 in the
HOST B) so that the eth1 of Host C can be considered as the eth0 of
HostB, so basically, all the traffic on eth1 of the Host C is going
to/coming from the Host B (the VM).
Since the Host B can be considered as a bridge, or just simply, a wire,
all this traffic gets out on eth1 of Host B, so back in the Host C as
vif1.1, which is part of a bridge which has an IP address : 10.168.254.250
This works fine, Host A can ping 10.168.254.250 (Host C) and we can see
the traffic going through Host B with tcpdump.
So it's like if there was no PEP stuff and eth1 had the IP address
10.168.254.250.
Now as you can see, on eth0 of Host C, we have a bridge with the IP
address 172.16.33.200. Host D can ping this IP address.
So we have both sides able to ping the gateway.
But now, I want Host A to be able to reach Host D through hosts C+B.
Regarding the routes : Host A has 10.168.254.250 (Host C) as a default
route, so when Host A wants to reach Host D, it sends the packets to
Host C+B.
Then, I tried to setup a route on Host D so that traffic to the subnet
10.168.254.0 goes through 172.16.33.200 and this works, Host A can
successfuly ping Host D.
But now, I want to get rid of the need of a special route on host D, so
I want to setup DNAT/Masquerade on the Host C.
Therefore, I have done this :
iptables -t nat -A POSTROUTING -o xenbr0 -j MASQUERADE
But when I ping D on A, and I look at what D receives, I can see the
real IP address of A, instead of the IP address of C (172.16.33.200)
I tried to do this as well :
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
But this doesn't solve my problem.
Now, as a final test, I tried to ping host D from host B (the VM) and in
this case, I get masqueraded packets, with this rule :
iptables -t nat -A POSTROUTING -o xenbr0 -j MASQUERADE
So I suspect that on Host C, the packets that comes in the eth1 NIC are
not just forwarded to the VM by the bridge, but detected somehow by the
network stack and forwarded to eth0 (by some layer2 code ?) without
being masqueraded, then.
I have been working on trying to solve this during 2 days now but still
I can't find a solution.
Can anyone have a quick look and hopefully provide me an explaination
and maybe some help to find a solution ?
Best regards,
--
Francois Goudal
Satcom1
next reply other threads:[~2008-06-23 14:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-23 14:22 Francois Goudal [this message]
2008-06-23 15:02 ` NAT issue on a machine with both routing and bridging Grant Taylor
2008-06-23 15:25 ` Francois Goudal
2008-06-23 15:48 ` Grant Taylor
2008-06-23 16:00 ` Francois Goudal
2008-06-23 16:42 ` Grant Taylor
2008-06-24 8:41 ` Francois Goudal
2008-06-24 14:29 ` Grant Taylor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=485FB19D.9080908@satcom1.com \
--to=fg@satcom1.com \
--cc=netfilter@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox