Re: iptraffic routing



On 29 Jul 2006, in the Usenet newsgroup comp.os.linux.networking, in article
<1154201455.339696.140620@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, 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/unreliable-guides/NAT-HOWTO/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
.



Relevant Pages

  • Re: Pros & cons with stealth?
    ... "Upon receiving the ACK/RST client from the target host, ... Winsock implementation of TCP, a pending connection will keep attempting to ... I captured all packets to ...
    (comp.security.firewalls)
  • Re: Client connection gets forcibly closed by Server
    ... both machines and see if you can see any RST packets coming from the ... the connection and if you look around that packet you might see why it ... SQL Server Developer Support Engineer ... For the PC client I am using a Toshiba A205 Satelite ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Pros & cons with stealth?
    ... I used a number of different Windows raw TCP connect tools (Essential Net ... few others), to establish a connection with TESTBED, first denying, then ... 3 attempts were made by each client to establish the ... Each transaction of 3 SYN and RST ACK packets was 372 bytes. ...
    (comp.security.firewalls)
  • close_wait state lost?
    ... tcpdump: verbose output suppressed, use -v or -vv for full protocol decode ... 134 packets received by filter ... The client was a month old 6.0-current (also verified with a march ... TCP_NODELAY and tries to cache the connection. ...
    (freebsd-net)
  • Re: Slow throughput problem
    ... There was a client connecting to our server using Tcp protocol. ... the packets reach the server one by one and the time gap ... there is no concurrent/parallel connection in this case). ...
    (comp.lang.java.programmer)