|
||||||||
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 subnets/gateways. Basically, what you're talking about doing is a 'hacked to hell version of this: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a 0080094adb.shtml 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. -Mike > -----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 the > network. i did not understand what it fully do, but it is done by assigning > /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 saw > it, > what I am thinking of is ISC DHCP can assign a static route for a client. > 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 as > 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 being > assigned. However, any subnet-mask option declaration that > is > in > scope for the address being assigned will override the subnet > mask specified in the subnet declaration. > > option routers ip-address [, ip-address ...]; > The routers option specifies a list of IP addresses for routers > on the client's subnet. Routers should be listed in order of > preference. > > option mask-supplier flag; > This option specifies whether or not the client should respond > to > subnet mask requests using ICMP. A value of 0 indicates that > the > client should not respond. A value of 1 means that the client > should respond. > option static-routes ip-address ip-address [, ip-address ip-address ...]; > This option specifies a list of static routes that the client > should install in its routing cache. If multiple routes to the > same destination are specified, they are listed in descending > order of priority. > > The routes consist of a list of IP address pairs. The first > address is the destination address, and the second address is > the > router for the destination. > > The default route (0.0.0.0) is an illegal destination for a > static route. To specify the default route, use the routers > option. > > With combination of these we could isolate clients on wired networks > We even after that could use dhcp to disconnect clients bye assigning fake > 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 above. > And to migrate to that software is like impossible to me, 1st it is not > "free" and I already started with m0n0wall from the beginning of my career > 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 time > after FreeBSD 6.4 update. But I am not asking for every thing, I am only > 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 than > 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 |