I agree, deny by default, and letting thru what is good is the way to
I've managed to deny down to the point that the world outside of the
communicate with an "invalid" ip on one of the guests.
I just need to whittle away a little more, restricting guest to guest
and host to guest.
Your approach is to use routing to drop unwanted traffic?
This would circumvent ebtables althogether. Is this essentially
Martin Maney wrote:
On Fri, Aug 06, 2004 at 10:47:30AM -0700, tim doyle wrote:
Could anyone point me in the right direction on controlling public ips
on guest umls?
The direction I have been going is to use ebtables to control what
frames get forwarded, and
to silently drop any unwanted frames.
Since there's no way to control what IP address(es) the guest kernel
configure from the host side, something along those lines is the only
sort of control you can have, yes.
Does anyone know of a more complete ruleset, one that handles arp as well?
According to http://ebtables.sourceforge.net/documentation.html,
ebtables has ARP filtering capability, though the docs also refer in
passing to a separate-sounding arptables. Not having used either, and
having read only what little is in their FAQ about arptables, I can
only point you in that direction.
Is this the same setup that was discussed a while ago? If so, "I told
you so" that it wasn't going to be easy to plug all the potential holes
in a bridging setup. :-/ Bridging is "allow by default", and as usual
it can get messy trying to plug holes; it might be easier to use a
deny-by-default setup (in this context, that would be something routed;
I forget what constraints you had such as IPs to expend, etc.) where
you open up only the access that you want to permit. Easiest would be
if you could setup a separate /30 for each guest, with simple routing
(and likely some ARP proxying) on the host side. That will block
wrongly-addressed IP traffic by default, leaving less to mop up.