All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jim Redman <jredman@ergotech.com>
To: lartc@vger.kernel.org
Subject: Re: ARP Help (was - [LARTC] snooping - plan B)
Date: Wed, 30 Jul 2003 16:01:07 +0000	[thread overview]
Message-ID: <marc-lartc-105958098107343@msgid-missing> (raw)

Thanks for the help from the list so far.  It's now reduced to an ARP 
problem.

host0
192.168.253.1----snoopy(eth0 192.168.253.254)

Now ping 192.168.253.2 and get snoopy to respond.  This can be done 
with netfilter (but not, apparently with ip).

iptables -A PREROUTING -t nat -p icmp -d 192.168.253.2 -j DNAT --to 
192.168.253.254
/sbin/arp -i eth0 -Ds 192.168.253.2 eth0 pub

gets you a "host unreachable" from 192.168.253.1

BUT if on host0 you:

/sbin/arp -s 192.168.253.2  HWADDR

then ping goes through.

Help from ARP experts (or others!) much appreciated.

Jim

On 2003.07.30 00:49, Martin A. Brown wrote:
> Jim,
> 
> First, let me say that I may not have caught all of your plan...but
> here
> goes....
> 
> If you really wish to modify application layer data, shouldn't you be
> looking at divert sockets [1], tun/tap usage [2], or optimally
> home-grown
> code?
> 
>  : OK, assuming this to be impossible.  Let's try the ARP approach.  I
>  : want to set up eth0 with ip 192.168.3.1 nat all packet addressed to
>  : 192.168.1.1 to 192.168.3.1 and ARP the address of 192.168.1.1 into
>  : eth0.  I still have some problems, any suggestions appreciated.
>  : Here's what I've tried (along with many variations):
> 
> Hmmmmm....  I haven't ever tried to do exactly what you seem to
> suggest
> here, but this may be an interesting approach.  If you are going to
> use
> NAT to solve your problem, you can try NATting each host into the
> other.
> 
>  : arp -i eth0 -Ds 192.168.1.1 eth0 pub
>  : ip route add nat 192.168.1.1 via 192.168.3.1
>  : ip rule add from 192.168.3.1 nat 192.168.1.1
> 
>  [ Note: I'm using the IP ranges you suggested in a prior mail. ]
> 
>   host-0                  +--------+               host-1
> 192.168.253.1 <--> eth0 <-- snoopy --> eth1 <--> 192.168.253.2
>                           +--------+
> 
> Assuming that you want host-0 to reach host-1, but only through
> snoopy,
> and you don't want to alter any network addressing on either host-0 or
> host-1:
> 
> # ip route add 192.168.253.1 dev eth0
> # ip route add 192.168.253.2 dev eth1
> # ip route add nat 192.168.253.102 via 192.168.253.2 iif eth0
> # ip rule add nat 192.168.253.102 from 192.168.253.2 iif eth1
> # ip route add nat 192.168.253.101 via 192.168.253.1 iif eth1
> # ip rule add nat 192.168.253.101 from 192.168.253.1 iif eth0
> 
> The nat route entry in the local routing table will take care of the
> ARP
> advertising for you, so any packets from host-0 addressed to
> 192.168.253.102 should end up on 192.168.253.2, but with a source
> address
> of 192.168.253.101.
> 
> So, a packet from host-0 to host-1 will look like this....
> 
>            host-0 side of      snoopy      host-1 side of
> 
>  Source: 192.168.253.1                   192.168.253.101
>    Dest: 192.168.253.102                 192.168.253.2
> 
> To me, this looks terribly convoluted and rather messy, not to mention
> that I have never tried it!  Nonetheless, I think this should work,
> provided that the nat IPs you choose are not in use anywhere else in
> your
> 192.168.253.0/24 network.
> 
>  : this alone is not sufficient, so I've tried adding routes for
>  : 192.168.1.1
>  : ip route add 192.168.1.1 dev eth0
>  : and so forth.  I haven't yet been successful and would apprciate
> any
>  : help.
> 
> Now, if I might make another recommendation....
> 
> Take a look at bridging [3].  This project has been maturing very
> nicely,
> and there have been very happy rumbles from people using the linux
> bridging code.  With the help of IP mode [4], you may get the control
> you
> desire.  Also look at the bridge + firewall documentation [5] and make
> sure to fetch the br+nf patches if you are using a 2.4 kernel [6].
> 
> Good luck,
> 
> -Martin
> 
>   [1]  http://152.45.4.41/~divert/index.shtml
>   [2]  http://vtun.sourceforge.net/tun/
>   [3]  http://bridge.sourceforge.net/
>   [4]  http://www.ssi.bg/~ja/bridging.txt
>   [5]  http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html
>   [6]  http://sourceforge.net/projects/ebtables/
> 
> 
> --
> Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com
> 

-- 

Jim Redman
(505) 662 5156 x85
http://www.ergotech.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

             reply	other threads:[~2003-07-30 16:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-30 16:01 Jim Redman [this message]
2003-07-31  2:37 ` ARP Help (was - [LARTC] snooping - plan B) Martin A. Brown

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-105958098107343@msgid-missing \
    --to=jredman@ergotech.com \
    --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.