> >    2) How to publish arp info correctly, so that my gateway does
> >    not answer to arp queries from inside the subnet, only to the
> > outside?
> 
> Funny, Marius Strobl (CC'd) told me about this problem a week ago. It
> seems this is a fundamental flaw in the BSD network stack in that it
> doesn't keep arp-entries per-interface for all interfaces. Solution would
> be to add a interface in the kernel list for which interface the arp entry
> is valid - unfortunately that's not done right now.

well, i'm not sure if this should be called a "flaw" as a arp-per-interface
feature is only needed in really broken network setups where something
like "bridging through routing" is needed. i'd consider it as somewhat
ugly if support for this would be added to *bsd, though it would be
usefull sometimes...

a only had 

> 
> There seems to be a solution that involves some userland daemon, but I
> don't know which one. I'll let Marius answer this. ;)
> 

that specific solution i mentioned to you is choparp which listens for
and answers the arp requests through a berkeley packet filter, we
toyed with it at franken.de (there the /24 subnet also _must_ not split
up but the traffic to the leased lines _must_ be "routed" through a
gateway...bad rules) until some other guys installed linux on the
gateway which is capable of doing arp-per-interface, so that would be
another "solution"...

some other workaround you could do is to change the 192.168.30.128/28
subnet to e.g. 10.1.1.1/28 or some other rfc1918 subnet not in 192.168/16
and to do address redirect through nat on the gateway. i used that some
time ago on a network until i set up clean subnetting. iirc, you would also
need proxy arp entries on the gateway machine (atleast with fbsd 3.4 and
natd i did) but the nat workaround saves you from "<gateway mac address>
is using my ip!" on the machines in 192.168.30.128/28

btw, when we had this problem at franken.de we didn't care about the
"...using my ip!" messages at first but the machines on the leased
lines with dsl bridges somehow menaged to "poison" the arp caches on
the machines in front of the gateway with their real mac address what
blew up the whole thing...was quite funny :)