All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Goldblatt <JonathanGoldblatt@CompuServe.Com>
To: Mike Jagdis <jaggy@purplet.demon.co.uk>
Cc: Matt Garman <garman@raw-sewage.net>, linux-diald@vger.kernel.org
Subject: Re: diald slow to be useful...
Date: 30 May 2002 14:24:23 -0400	[thread overview]
Message-ID: <m3elfta3zc.fsf@localhost.localdomain> (raw)
In-Reply-To: <3CF60FE6.2030504@purplet.demon.co.uk>

Mike Jagdis <jaggy@purplet.demon.co.uk> writes:

> 
> 3. Hacker voodoo :-). If you know what you are doing you can
> change your firewall set up so that it *doesn't* masquerade
> traffic sent to diald's proxy interface. How you do that depends
> on whether your use ipchains (-i ! sl+) or iptables (-o ! sl+),
> and how your distribution does firewall config. In dynamic
> (or sticky) mode diald forwards buffered packets back in to
> the kernel via the proxy rather than straight out on the
> real link. So the kernel first routes the packet to diald
> *without* masquerading it, diald brings the link up and
> sends the packet back to the kernel, which then routes
> it to the link and *does* masquerade it - with the correct
> address! This should work for all connections even if you
> get a different address every time. But you're probably
> going to have to understand firewalling, read man pages,
> and edit shell scripts to do it[*].
> 
> 				Mike

> [*] If anyone does this *please* let us know what you needed
> to change!

In the script where I turned on IP masquerading with:

# Do masquerading
echo 1 > /proc/sys/net/ipv4/ip_forward
/sbin/ipchains -A forward  -j MASQ

I changed it to:

# Do masquerading
echo 1 > /proc/sys/net/ipv4/ip_forward
/sbin/ipchains -A forward -i ! sl+ -j MASQ
/sbin/ipchains -P forward ACCEPT

The last line was because I set all the policies to DENY when I
started the script for safety.  Took the time to make sure that the
problem was duplicated on my setup.  Your suggestion works like a
charm.

Hope this is helpful.  Wondering whether 2.0 is a redesign or
somesuch, what the TODOs might be, what goes into making a release, etc.  


  reply	other threads:[~2002-05-30 18:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-10  3:09 diald slow to be useful Matt Garman
2002-05-10 16:53 ` Mike Jagdis
     [not found]   ` <"from jaggy"@purplet.demon.co.uk>
2002-05-17 23:50     ` Matt Garman
2002-05-29  9:09       ` Mike Jagdis
2002-05-29 11:18     ` Matt Garman
2002-05-30 11:41       ` Mike Jagdis
2002-05-30 18:24         ` Jonathan Goldblatt [this message]
2002-06-27 11:27         ` Bjorn Hammarberg
2002-05-30  8:37 ` Robert Jenkins
2002-05-30 11:46   ` Mike Jagdis
2002-05-30 13:51     ` Robert Jenkins

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=m3elfta3zc.fsf@localhost.localdomain \
    --to=jonathangoldblatt@compuserve.com \
    --cc=garman@raw-sewage.net \
    --cc=jaggy@purplet.demon.co.uk \
    --cc=linux-diald@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.