[bdNOG] DHCP Lease and Network Problem Help (Mohammad Shahjahan)

Paul S. contact at winterei.se
Thu Dec 10 09:41:11 BDT 2015


Hi,

Just terminate whoever does it willingly.

Distribute a advisory stating that there will be strong penalties for 
intentional network disruptions, and then follow through with it.

That's the basis of all 'shared' services, so you shouldn't be met with 
any backlash from your real users. If you want, sugar coat it a bit.

On 12/10/2015 11:42 AM, Mohammad Shahjahan wrote:
> Dear Brian,
>
> Thank you so much for your cordial help. Your are right the access 
> list wont work because our network provide dhcp lease through a layer 
> 3 switch with several vlan's with ip helper address (192.168.1.1) as said.
>
> But there are no options to change helper ip address that because 
> there are lots of routing issue with other country's.
>
> So, that's why i think there are no hope to stop using GATEWAY IP 
> ADDRESS in android mobile user. We have to think about another 
> internet policy.
>
> I really appreciate about all of support and thank you so much.
>
> --------------------------------------------------------
> *Engr. Mohammad Shahjahan*
> Member of Institute of Engineer Bangladesh
> Membership Number: M/31195
> Chittagong, Bangladesh
> Contact Information: +8801752789798
> --------------------------------------------------------
>
>
> ------------------------------------------------------------------------
> To: nog at bdnog.org
> From: brian at nsrc.org
> Date: Mon, 7 Dec 2015 08:36:50 +0000
> Subject: Re: [bdNOG] DHCP Lease and Network Problem Help (Mohammad 
> Shahjahan)
>
> On 07/12/2015 06:00, nog-request at bdnog.org 
> <mailto:nog-request at bdnog.org> wrote:
>
>     For an Example: Suppose your gateway IP is 192.168.1.1, then you
>     can implement Standard ACL on the switchport (from where your
>     users are connected to)
>
>     Switch(config)#access-list 1 deny host 192.168.1.1
>     Switch(config)#access-list 1 permit any
>
>     Switch(config)#interface fastEthernet 0/1
>     Switch(config-if)#ip access-group 1 in
>
> I'm not sure that's going to help, unless it filters ARP responses as 
> well as IP datagrams. That is: it will stop the person with address 
> 192.168.1.1 from using the Internet, but it probably won't stop the 
> breakage of the other users.
>
> Consider a packet which is going out from PC 192.168.1.100 to the 
> Internet, say IP address 8.8.8.8.
>
> Neither of those packets has 192.168.1.1 as a source or destination 
> address, so it won't be affected by the filter. However, the PC knows 
> that its default gateway is 192.168.1.1, so will send an ARP request 
> for 192.168.1.1 to learn the MAC address.
>
> Your router will respond, but so will the hijacker who has manually 
> configured 192.168.1.1 as their IP address. Whichever response arrives 
> first will be the one which is used, so it's just a race.
>
> If the hijacker's response arrives first, the PC will encapsulate 
> their packet with the hijacker's MAC address and deliver it there 
> instead of to the Internet. If the hijacker has IP forwarding enabled 
> they may re-send it to the router (note that they will be able to 
> sniff all outbound traffic!) But most likely the packet will be 
> dropped on the floor and connectivity will be broken.
>
> So, to fix this problem properly you would have to do filtering of ARP 
> responses; enforce that ARP responses for 192.168.1.1 which enter 
> through a port other than the router's port are discarded. I believe 
> the Cisco "IP address tracking" feature might be able to do that.
>
> However a simpler approach may be to *detect* the problem: for example 
> by running a tool like arpwatch on that network segment. Then you have 
> an Acceptable Usage Policy which says that the manual configuration of 
> IP addresses is *forbidden* and will result in serious consequences 
> (make use of your company's or university's existing disciplinary 
> procedure)
>
> In my experience, the reason that people actually configure manual IP 
> addresses is because the DHCP service is unreliable, and they are 
> forced to do this to get work done. If that's the case, then the real 
> solution is to make your DHCP service reliable.
>
> It's fine to have two DHCP servers for redundancy:
>
> interface Foo
>   ip helper-address 192.0.0.1
>   ip helper-address 192.0.2.2
>
> The simplest way to make this work is to give the two DHCP servers 
> non-overlapping pools of addresses (e.g. 192.168.1.10-149 and 
> 192.168.1.150-249). This avoids then need to run DHCP clustering where 
> the two servers are both aware of each other's allocations.  The user 
> will receive two DHCP offers, will pick the first one and use that.
>
> Also it's better if your lease times are sufficiently large (say 12 
> hours) so that once they have an address at the start of the day, it 
> works all day. For that to work well you might need bigger subnets, 
> say a /22 instead of a /24, especially with wireless, but that's not a 
> problem if you are using private IP addresses.
>
> HTH,
>
> Brian.
>
>
> _______________________________________________ nog mailing list 
> nog at bdnog.org http://mailman.bdnog.org/mailman/listinfo/nog
>
>
> _______________________________________________
> nog mailing list
> nog at bdnog.org
> http://mailman.bdnog.org/mailman/listinfo/nog

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.bdnog.org/pipermail/nog/attachments/20151210/ff354d42/attachment-0001.html>


More information about the nog mailing list