Proxy ARP

[Jan Danielsson]

Hello,

Let's say I have a data diode separating two networks -- because the
data diode is unidirectional normal (dynamic) ARP won't work.
Workaround is to use static ARP tables, but in this hypothetical let's
also say that there are multiple sources and multiple destinations and
adding ARP tables manually on each system is a pain.

The solution is to tell a host (probably a subnet gateway) to fake
it and reply to all ARP requests relating to the destination addresses.

arp(8) seems to support this using the "pub" keyword. But what does
the "proxy" keyword do?

``[---] If the word pub is given, the entry will be "published";
i.e., this system will act as an ARP server, responding to requests for
hostname even though the host address is not its own. If the word proxy
is also given, the published entry will be a ``proxy only'' entry.''

What does "proxy only" mean here?

(I skimmed through the "Proxy ARP" thread from early 2016 by
ozaki-r@, but I'm not sure I found a reply that I understand).


Also, does ARP in any way associate the port/interface it receives a
reply on with the port/interface it expects to reach the host on?

Specifically: Say I have server S with an network interface wm0
which is connected to a regular LAN (192.168.0.y/24), on a separate host
on this LAN there's a Proxy ARP configured. wm1 is connected to the
"secret" network (10.0.0.x/24) through a data diode. The system can not
receive ARP replies through the data diode link, so it must rely on the
Proxy ARP, and for this hypothetical it is reachable on wm0.

Will S (running NetBSD) send the "who/where is 10.0.0.X?" ARP
request on wm0 or will it subnet mask match and only send it on wm1?

Assuming ARP's are sent on non-matching interfaces, if the Proxy ARP
has a hard-coded entry for 10.0.0.Y, which S will receive through wm0,
will it understand that "yes, you received this on wm0, but the address
is within wm1, so use that port/interface instead"?

My assumption is that there needs to be a Proxy ARP *before* the
data diode on wm1 (i.e. it can't use wm0 for this), but it would be neat
if that isn't the case.

[Joerg Sonnenberger]

Let's say I have a data diode separating two networks -- because the data
diode is unidirectional normal (dynamic) ARP won't work. Workaround is to
use static ARP tables, but in this hypothetical let's also say that there
are multiple sources and multiple destinations and adding ARP tables
manually on each system is a pain.

Take a look at Roy's parpd. I've been using it in the past to do
subnetting for virtual machines without a bridge.

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Joerg Sonnenberger

Let's say I have a data diode separating two networks -- because the data
diode is unidirectional normal (dynamic) ARP won't work. Workaround is to
use static ARP tables, but in this hypothetical let's also say that there
are multiple sources and multiple destinations and adding ARP tables
manually on each system is a pain.

Take a look at Roy's parpd. I've been using it in the past to do
subnetting for virtual machines without a bridge.

https://roy.marples.name/projects/parpd

You can find it in pkgsrc under net/parpd

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Robert Elz]

Date: Tue, 6 Aug 2019 16:17:01 +0200
From: Jan Danielsson <***@gmail.com>
Message-ID: <f05ed9b2-62af-d4a4-ef87-***@gmail.com>

| arp(8) seems to support this using the "pub" keyword. But what does
| the "proxy" keyword do?

The difference between the two is that in one case, the ARP reply
gives the host's own MAC address as being associated with the IP
address - packets for the destination will be forwarded to the host
that is answering, which is then responsible for forwarding them
elsewhere. This is generally used when an apparent (to IP) single
link is actually several different physical links (different broadcast
domains). In the other case, the ARP reply uses some other host's
MAC address in the reply, so that packets for the destination will
be forwarded to it - it is (was) mostly used in the early days of
ARP when not all hosts supported that new protocol, and a host that
did use ARP was attempting to communicate with one which did not.

| Also, does ARP in any way associate the port/interface it receives a
| reply on with the port/interface it expects to reach the host on?

It certainly should. The IP layer routes outgoing packets to a
particular interface - then ARP is used (by the interface driver
at least in the model, if not always in practice any more) to determine
the destination MAC address for the packet - the request is broadcast,
and the reply must come back on that same interface.

This is important, as the same IP address can be owned by different
hosts on different links (think link local addresses as an example)
and on each interface the "same" IP address will be associated with
a different MAC address.

| Will S (running NetBSD) send the "who/where is 10.0.0.X?" ARP
| request on wm0 or will it subnet mask match and only send it on wm1?

If routing says to use wm1, then wm1 is where the ARP request goes.

| My assumption is that there needs to be a Proxy ARP *before* the
| data diode on wm1 (i.e. it can't use wm0 for this), but it would be neat
| if that isn't the case.

Your assumption is right.

kre


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Andy Ruhl]

Post by Robert Elz
be forwarded to it - it is (was) mostly used in the early days of
ARP when not all hosts supported that new protocol, and a host that
did use ARP was attempting to communicate with one which did not.

I'm hoping someone will indulge me for a few minutes. I'm trying to be
a "network guy" in the real world. I went to Roy's page for parpd and
then read part of the RFC he points to as the reason for parpd's
existence.

What is the modern need for this? I know some redundant gateway
protocols do interesting things with arps and replies because mac
adresses move around, but they don't need parpd. Otherwise, it seems
like a static arp entry would work for most people, certainly in the
case of heavy filtering. If the mac changes, and breaks this, you
would really want to know that I think.

Anyway, I'm probably missing something.

Andy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Simon Burge]

[ parpd ]
What is the modern need for this? [ ... ]

In my case I have a system with a wm(4) card that just refuses to
respond to ARP requests sometimes. Inconvenient if it happens to
be your router :). parpd works really well for me.

Cheers,
Simon.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Andy Ruhl]

Post by Simon Burge
In my case I have a system with a wm(4) card that just refuses to
respond to ARP requests sometimes. Inconvenient if it happens to
be your router :). parpd works really well for me.

Wow, learned another thing today. The ethernet driver responds to arp
requests. I used a few wm adapters and I don't remember any arp
issues.

Andy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jan Danielsson]

On 2019-08-08 00:48, Simon Burge wrote:
[---]

Post by Simon Burge
In my case I have a system with a wm(4) card that just refuses to
respond to ARP requests sometimes. Inconvenient if it happens to
be your router :). parpd works really well for me.

Hmm.. You may have [completely unprovoked] solved a slightly
annoying mystery for me. This wm(4) ARP bug; how often does it happen
-- and does it affect NetBSD 7.1?

[i***@netbsd.org]

Hi,

Post by Andy Ruhl
What is the modern need for this?

I've used proxy arp to embed a few mobile workstations behind a PPP link
into some lan (arp .... proxy in the link-up script, and arp -d in the
link-down script).

The proxyarpd's README I've (later) read had a similar usecase -
connecting two lans through a machine (or two machines with a PPP link).

This was when most LANs were physically broadcasting media (Real
Ethernet (tm)) and el cheapo people didn't have bridges and operating
systems didn't have bridge devices.

Also - when you didn't have enough addresses to get another 'net, but
a hole big enough to loan it on the other physical LAN...

But you asked about MODERN needs, so ignore this old mans memories.

-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Andy Ruhl]

Post by i***@netbsd.org
I've used proxy arp to embed a few mobile workstations behind a PPP link
into some lan (arp .... proxy in the link-up script, and arp -d in the
link-down script).

Thanks. Got it, didn't think about situations like this. I don't have
to use PPP often.

History is important. It's useful to remember that there was a time
before arp was a thing, or switches, dhcp, variable length subnetting
and all the rest.

Andy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

Post by Andy Ruhl

Post by Robert Elz
be forwarded to it - it is (was) mostly used in the early days of
ARP when not all hosts supported that new protocol, and a host that
did use ARP was attempting to communicate with one which did not.

I'm hoping someone will indulge me for a few minutes. I'm trying to be
a "network guy" in the real world. I went to Roy's page for parpd and
then read part of the RFC he points to as the reason for parpd's
existence.
What is the modern need for this?

My use case was getting an IPv4 /29 block to be shared with some public
services and an office network. The services were running as virtual
machines, so the alternative was using a bridge on the upstream
interface or proxy ARP with normal routing. The latter was actually
easier to handle.

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de