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 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.