Linux Advanced Routing and Traffic Control list
 help / color / mirror / Atom feed
From: Christian Stuellenberg <christian_stuellenberg@web.de>
To: lartc@vger.kernel.org
Subject: [LARTC] Re[4]: local address routeable?
Date: Fri, 18 Jul 2003 06:18:59 +0000	[thread overview]
Message-ID: <marc-lartc-105850926120730@msgid-missing> (raw)

>>>>> "Christian" = Christian Stuellenberg <christian_stuellenberg@web.de> writes:
>>>>> "Julian" = Julian Anastasov <ja@ssi.bg> writes:
Hello,

    Christian> If traffic from zone MASQ is addressed to one of the
    Christian> external internet addresses of one of the zone GOOD or
    Christian> DMZ, then it will currently get routed directly at
    Christian> HOST.  It is intended, that this direct routing is not
    Christian> done, but instead ALL traffic from zone MASQ becomes
    Christian> masqueraded out over the dynamic PPP connection to the
    Christian> internet, comes back over the CISCO line to HOST, then
    Christian> gets routed to the extern destination IP (in zone GOOD
    Christian> or DMZ) and when the reply from there comes back again
    Christian> to HOST, it should get routed over the CISCO internet
    Christian> connection and then back over the dynamic PPP
    Christian> connection, demasqueraded, and at last delivered to the
    Christian> original source in zone MASQ.

    Christian> This works up to the point, where the reply comes back
    Christian> to HOST.  Now I'm not able to tell HOST, that this
    Christian> reply should again routed out to the internet over the
    Christian> CISCO line and only demasqueraded if it comes in over
    Christian> the PPP connection (btw.  the demasquerading does also
    Christian> not occur if the reply gets not routed; I assume, this
    Christian> is because the masquerding tables are waiting for a
    Christian> packet that comes in over the PPP connection and not on
    Christian> IF0 or IF1).

    Julian> 	I think, I understand the setup. I'm still wondering
    Julian> what is the end goal. I can only speculate:

    Julian> Assumption 1. Hosts from GOOD want to see client from
    Julian> DynIP, not from a.b.c.62. The solution: use SNAT with
    Julian> saddr=DynIP when talking to GOOD because the default
    Julian> masquerade action is to use a.b.c.62 which is recommended
    Julian> from the routing. I assume GOOD and DMZ do not care how
    Julian> the packet with saddr=DynIP appeared as long as it looks
    Julian> as expected?

    Julian> 2. For some reason (even by introducing security problems)
    Julian> you want packets with saddr=DynIP to walk the external
    Julian> path and to reach GOOD. Is it needed? Is there a problem
    Julian> with the above solution in #1?

I really want the long path, so that a client in zone MASQ can test,
whether both uplinks to the internet work correctly.  Not only to test
the links, but also to provide a way, that a client in zone MASQ looks
like any other (actually masqueraded) client in the world.  We
would'nt achieve that, if the routing from a client in zone MASQ takes
directly place on HOST.

Regards,
Christian

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

                 reply	other threads:[~2003-07-18  6:18 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=marc-lartc-105850926120730@msgid-missing \
    --to=christian_stuellenberg@web.de \
    --cc=lartc@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