On 29 Jul 2006, in the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed) .com>, fdusin wrote:
>let's say i have 2 pcs connected to the internet. each one has a public
>ip address from a totally different subnet.
>
>pc1 should now accept connections on port 80 and forward them to pc2.
OK - standard port forwarding
>pc2 has a webserver running, processes the request and should then
>reply DIRECTLY to the client, so bypassing pc1.
There's one heck of a conceptual problem here.
>speaking of packets, pc1 should get the packets from the client, forward
>them to pc2, pc2 processes the request and sends the answer packets
>directly to the client (and not over pc1). so pc1 has only incomming
>traffic (from client), while pc2 has incomming (from pc1, forwarded from
>client) and outgoing traffic (to client)
No, that doesn't translate any better. Hmmm, where to start? Let's try
1180 TCP/IP tutorial. T.J. Socolofsky, C.J. Kale. January 1991.
(Format: TXT=65494 bytes) (Status: INFORMATIONAL)
Really, really brief. Web browser on some client wants a web page. It asks
the kernel to establish a TCP connection to the web server on host X. To
do so, the kernel sends a SYN packet directed to an IP address and port
number. It expects a reply with a SYN/ACK _from_that_IP_address_and_port_number.
A packet "returning" from any other address/port is NOT going to establish
the conversation link needed for the web browser to then send an HTTP
"GET" command. Result - no connection, and no web page.
2616 Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J. Gettys,
J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. June
1999. (Format: TXT=422317, PS=5529857, PDF=550558 bytes) (Obsoletes
RFC2068) (Updated by RFC2817) (Status: DRAFT STANDARD)
Now, on the other hand, you may mean establishing the TCP connection with
host N, sending the GET command, and being redirected to host P which is
going to actually serve the page. That's a whole 'nother bowl of tar,
with it's own warts (and newsgroups - try comp.infosystems.
www.authoring.*)
>i though doing this using iptables should be quite easy:
>1. forward all packets arriving at pc1 on port 80 to pc2.
>2. change the source-address of the outgoing packets from pc2 to the ip
>of pc1 so the clients see the packets comming from pc1 while in realtiy
>they come from pc2.
This is classic masquerading, and is different from what you wrote above.
Here, the clients think everything is happening on pc1, and pc2 doesn't even
exist. See
-rw-rw-r-- 1 gferg ldp 708351 Nov 14 2005 IP-Masquerade-HOWTO
-rw-rw-r-- 1 gferg ldp 17605 Jul 21 2004 Masquerading-Simple-HOWTO
which should be on your system. Rusty Russell (author of the firewall code)
also has an older page called the NAT-HOWTO, available from
http://netfilter.filewatcher.org/unr...WTO/index.html.
>unluckily this does not work, but i don't know why! :-(
The way to find out is to run two instances of 'tcpdump' on pc1, watching
the two interfaces (one to the client - one to pc2). Now, if pc1 has only
one NIC, that's an entirely different problem, and this would be making the
network stack unhappy as to why packets coming in on this interface are
being forwarded back out the same interface - "why doesn't the stupid client
go direct and not bother me?". Re-reading your first sentence "each one has
a public ip address from a totally different subnet", if you are sending the
packets between pc1 and pc2 _over_the_Internet_ and not via a "local" link,
things are _really_ going to get hairy. You _don't_ want to go there.
>i'm really looking forward to any suggestions. may be doing it by some
>tunnel or what ever is much better than trying to do this with
>iptables?
Maybe a better description of what you are trying to do would help.
Old guy
Similar Threads
Linear Mode
