All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fabio De Paolis <fabiodepaolis@naxe.it>
To: netfilter@vger.kernel.org
Subject: Re: NAT Port Forward problem in a not so simple network
Date: Fri, 18 Apr 2008 15:43:03 +0200	[thread overview]
Message-ID: <4808A567.5090507@naxe.it> (raw)
In-Reply-To: <48060E8C.5010804@riverviewtech.net>

Grant Taylor ha scritto:
>
>> Yes on my knowledge I know that it can't be done without doubling the 
>> traffic on the net. I was wondering if at yuor knowledge the was 
>> another way. Of course if I could nat a port from A to B it would be 
>> easy and the traffic will me at minimum, but it cant be done. I was 
>> wondering if there was a way to use C only for initial handshake and 
>> not for all packets, but it seems no.
>
> Strictly speaking, on layer 3, no there is not any thing (that I am 
> aware of) that can be done.  However if you are willing to go down to 
> in between layers 2 and 3 or even down to layer 2 there might be 
> something that can be done.
>
>          +---+
>          | Z |
>          +-+-+
>            |
>            :       (INet)
>            |
>          +-+-+
> =========| A |============
>          +-+-+
>            |
>    +---+---+---+   (DMZ)
>    |   |       |
>    | +-+-+   +-+-+
> ===|=| B |===| C |========
>    | +-+-+   +---+
>    |   |           (LAN)
>    | +-+-+
>    +-+ D |
>      +---+
>
> I'm guessing that there are other services on C that prevent you from 
> moving it's IP to B.  Correct?
>
> I'm not sure how well this will work out (read:  I don't know how well 
> the Cisco will play in this game...) but you might be able to 
> establish some sort of tunnel based forwarding from C to D so that 
> inbound requests pass through the tunnel and replies go directly from 
> D back out via A to the client.
>
> Let's say for the sake of discussion that you add a connection from D 
> back in to the DMZ (as above) and have this interface configured to 
> *NOT* respond to ARP requests.  If you do this, you could have the 
> same IP bound to C as well as the new DMZ facing interface on D.  With 
> this type of set up, you could tunnel traffic from C to D via B and 
> have D reply directly back with out passing through B or C.
>
> In short, this is using the IP Tunnel mode of Linux Virtual Server to 
> turn C in to a director for the single node back end.  As such, your 
> client Z would connect to Ae which is port forwarded to Ce which is 
> tunnel to D which processes and replies to the client from the same IP 
> as Ce.  This means that A will send traffic to the IP that is bound to 
> Ce and get replies from the same IP only bound to D's DMZ interface. 
> The only difference that A should see is a different MAC address as 
> the source for the reply traffic.  However, if you spoof the MAC 
> address, this will not be a problem.  If you do spoof the MAC address 
> you will need to do something like GARP to make sure the DMZ switch 
> does not ""learn that the location of the shared MAC address is where 
> D's DMZ interface is connected.
>
Thank you for the lesson.

D is too far from C's switch *sad*
and I think I can't add another cable

  reply	other threads:[~2008-04-18 13:43 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-15  9:48 NAT Port Forward problem in a not so simple network Fabio De Paolis
2008-04-15 12:15 ` whiplash
2008-04-15 15:01   ` Grant Taylor
2008-04-17 14:49     ` Pascal Hambourg
2008-04-17 14:56       ` Grant Taylor
2008-04-15 14:57 ` Grant Taylor
2008-04-15 16:22   ` Fabio De Paolis
2008-04-15 16:45     ` Grant Taylor
2008-04-16 13:54       ` Fabio De Paolis
2008-04-16 14:34         ` Grant Taylor
2008-04-18 13:43           ` Fabio De Paolis [this message]
2008-04-18 14:46             ` Grant Taylor
  -- strict thread matches above, loose matches on Subject: below --
2009-01-27 19:10 Fabio De Paolis
2009-01-27 20:34 ` Marek Kierdelewicz

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=4808A567.5090507@naxe.it \
    --to=fabiodepaolis@naxe.it \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.