Date: Thu, 30 Jan 1997 00:11:56 +0000 From: Brian Somers <brian@awfulhak.demon.co.uk> To: Archie Cobbs <archie@whistle.com> Cc: terry@lambert.org, ari.suutari@ps.carel.fi, hackers@freebsd.org, cmott@srv.net Subject: Re: ipdivert & masqd Message-ID: <199701300011.AAA15020@awfulhak.demon.co.uk> In-Reply-To: Your message of "Wed, 29 Jan 1997 15:47:14 PST." <199701292347.PAA25117@bubba.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>
> > Not exactly - on my machine, there are two problems (3.0-current). The
> > machine that's doing the masquerading is 10.0.1.254.
> >
> > 1. When I do a tcp setup from 10.0.1.254 to 10.0.1.1, the packet goes out
> > ok, 10.0.1.1 receives it and replies (netstat shows ESTABLISHED).
> > Masqd/natd receives the packet, fixes it and re-injects it.... then,
> > all of a sudden, nothing happens. After a long wait, nothing continues
> > to happen :( It's as if the ip_sum is wrong, but I don't believe that
> > yet as it works ok when there are two divert sockets involved.
> >
> > 2. When a ping is sent from 10.0.1.1 to 10.0.1.254, the incoming icmp
> > packet is picked up by masqd/natd, fondled and re-injected. That's
> > *all* that masqd/natd sees. However, 10.0.1.1 gets an ICMP reply.
>
> Hmmm.. a couple of questions, trying to understand the setup. Sorry if
> this is starting to get tiring... :-)
>
> - What is your network topology (ASCII art if possible)? That is,
> what IP interfaces are on what networks with what addresses assigned?
>
> - What are the ipfw rules that are installed on the diverting machine?
>
> - Why are any packets having their IP addresses remapped if the two
> machines (at 10.0.1.254 and 10.0.1.1) are on the same subnet?
>
> Also, if netstat shows ESTABLISHED (on either end), then at least
> one packet must have successfully made it across in both directions,
> due to the TCP handshaking involved in getting to that state.
>
> Thanks,
> -Archie
I've essentially got the following:
---------------- ----------------------
| 10.0.10.2 |------------------| 10.0.10.1 |
---------------- | |
| 10.0.1.254 (ed0) |
----------------------
|
|
----------------- |
| 10.0.1.1 |---------------------------
-----------------
with a mask of ffffff00 everywhere and the machine in the middle using
the following:
ipfw add 100 divert 6668 all from any to any via ed0
The masqd/natd programs then pick up all packets and call the packet
aliasing code. *All* packets get mangled so that there are no real/alias
port conflicts - that is, an outgoing packet to 10.0.1.1:21 from
10.0.1.254:1025 cannot keep the 1025 port because it may conflict with
an already existing "alias" port - making it impossible to figure out what
to do with the returning 10.0.1.254:1025 packet.
Instead, all packets have their source port changed to an alias port on the
way out, and changed back to what it should be on the way back in. A table
is maintained, mapping alias ports to real IP/port pairs.
Needless to say, the "point" behind this is to have the 10.0.10.0/24 network
connected to the 10.0.1.1/24 network through the 10.0.1.254 IP. The
problems with the 10.0.1.254 machine itself are a bit of a shame because
that's the machine that didn't need to do anything special in the first
place :)
--
Brian <brian@awfulhak.demon.co.uk>, <brian@freebsd.org>
<http://www.awfulhak.demon.co.uk/>;
Don't _EVER_ lose your sense of humour....
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701300011.AAA15020>