[ previous ] [ next ] [ threads ]
 From:  "Jewell, Michael" <mjewell at law dot umaryland dot edu>
 To:  <m0n0wall at lists dot m0n0 dot ch>
 Subject:  RE: [m0n0wall] Beta 1.3b17 released
 Date:  Mon, 17 Aug 2009 10:57:27 -0400
FYI - just because something is supported in a program, does not make it
a good idea to use it.  Using this violates the rules of IP

Basically, what you're talking about doing is a 'hacked to hell version
of this:

Problems with this:
	A. Broadcasts sent on the wire will still be seen by each and
every computer, because they are all still in the same broadcast domain.
Ie this will not prevent a virus from spreading via broadcasts.

	B. Assigning options via DHCP only works if the clients accept
the options.  Someone could see the dhcp options are incorrect for the
ietf standard and change it back to a (/24,/23,/22) subnet and now have
access to every machine.

	C. It's just a plain bad idea.

In the future, you're bound to run into machines that barf when you try
to give them an invalid gateway.


> -----Original Message-----
> From: Mohammed Ismail [mailto:m dot ismael at gmail dot com]
> Sent: Monday, August 17, 2009 2:44 AM
> To: 'Mohammed Ismail'; m0n0wall at lists dot m0n0 dot ch
> Subject: RE: [m0n0wall] Beta 1.3b17 released
> Note : Sorry for incomplete message
> -----Original Message-----
> From: Mohammed Ismail [mailto:m dot ismael at gmail dot com]
> Sent: Monday, August 17, 2009 9:22 AM
> To: 'Chris Buechler'
> Cc: 'm0n0wall at lists dot m0n0 dot ch'
> Subject: RE: [m0n0wall] Beta 1.3b17 released
> Chris wrote:
> "Windows doesn't care about it, if it can ARP the IP, it'll use it as
> its gateway. Other OSes will not do this, your network will not be
> usable with FreeBSD for sure (it refuses to add a clearly invalid
> default gateway), and likely others as well. It's ugly, don't do it.
> It's not solving anything you think it might be solving. Your biggest
> issue with internal untrusted clients is going to be ARP poisoning
> (whether done in an automated fashion by malware on user's PCs or by
> an attacker), which this isn't going to do anything to address, and is
> one example of many of why you need a real solution here. Because the
> problem is inside your network"
> >>>>
> >>
> .
> Let us say I used mikrotik router OS, it does some thing there inside
> network. i did not understand what it fully do, but it is done by
> /32 subnet mask , and with optional gateway other than LAN IP.
> I know this being silly every time I come with strange thing, I just
> it,
> what I am thinking of is ISC DHCP can assign a static route for a
> And many so found on
> http://www.freebsd.org/cgi/man.cgi?query=dhcp-
> options&apropos=0&sektion=5&ma
> npath=FreeBSD+6.4-RELEASE&format=html
> I am talking about
> option subnet-mask ip-address;
> 	     The subnet-mask option specifies the client's subnet mask
> per
> 	     RFC 950.  If no subnet-mask option is provided anywhere in
> scope,
> 	     as a last resort dhcpd(8) will use the subnet mask from the
> sub-
> 	     net declaration for the network on which an address is
> 	     assigned.	However, any subnet-mask option declaration that
> is
> in
> 	     scope for the address being assigned will override the
> 	     mask specified in the subnet declaration.
> option routers ip-address [, ip-address ...];
> 	     The routers option specifies a list of IP addresses for
> 	     on the client's subnet.  Routers should be listed in order
> 	     preference.
> option mask-supplier flag;
> 	     This option specifies whether or not the client should
> to
> 	     subnet mask requests using ICMP.  A value of 0 indicates
> the
> 	     client should not respond.  A value of 1 means that the
> 	     should respond.
> option static-routes ip-address ip-address [, ip-address ip-address
> 	     This option specifies a list of static routes that the
> 	     should install in its routing cache.  If multiple routes to
> 	     same destination are specified, they are listed in
> 	     order of priority.
> 	     The routes consist of a list of IP address pairs.	The
> 	     address is the destination address, and the second address
> the
> 	     router for the destination.
> 	     The default route ( is an illegal destination for a
> 	     static route.  To specify the default route, use the
> 	     option.
> With combination of these we could isolate clients on wired networks
> We even after that could use dhcp to disconnect clients bye assigning
> IP address if arp attack is detected.
> So I totally disagree with the following.
> =======================
> "m0n0wall isn't part of the solution as
> it can't control these things (aside from the likely infeasible option
> of splitting each user onto their own VLAN trunked to m0n0wall"
> >>>>>>>>>>>>>>..
> >>
> .
> It is the solution, I know arp is layer2 but it is just as I said
> And to migrate to that software is like impossible to me, 1st it is
> "free" and I already started with m0n0wall from the beginning of my
> and it is like emotionally connected to it for being FreeBSD.
> With some work I guess it could be done.
> And I have like 15 device running m0n0wall each provide Internet
Access for
> 75 to 150 Wired Clients. Some networks are OK and others are not.
> We could use them for testing.
> I know I could start a new image, which I hope to work with me this
> after FreeBSD 6.4 update. But I am not asking for every thing, I am
> talking about making strong DHCP server for m0n0wall.
> Yesterday I saw m0n0AP still under b1, but I guess it will be
promising for
> being m0n0wall based, unlike Pfsense which is going in other direction
> m0n0wall.
> Best Regards ,
> Mohammed
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch