Re: [Strange behavior with arp permanent entries]

ea@xxxxxxxxxxxx wrote:
ea@xxxxxxxxxxxx wrote:
Hello, Guys!

I'm trying to restrict some LAN access by arp permanent entries. But it
didn't work or it didn't work as I realize it. For example I have the
following perm entries:


user1: (82.199.215.195) at 00:0f:ea:a4:60:c5 on vlan804 permanent [vlan]
user2: (82.199.215.196) at 00:13:8f:b1:68:4b on vlan804 permanent [vlan]


And from what I realize if the user1 attempts to use user2's IP address.
The Router should block all packets which coming from wrong physical
address. But actually that didn't happen and user1 can use user2's IP
address without any problems.
The router wont block packets coming from anyone. It should however
prevent packets going *to* the wrong user. But that depends heavily on
whether the layer2 network cooperates and the bad hosts network stack.

Scenario 1:

user1: 10.2.0.2 00:14:85:84:af:c8 perm
user2: 10.2.0.3 00:0f:ea:a4:60:c5 perm

User2 can't use user1's IP address.

Scenario 2:

user1: 10.2.0.2 00:0a:e6:f7:8a:81 perm
user2: 10.2.0.3 00:0f:ea:a4:60:c5 perm

User2 can use user1's IP address.

So, maybe there is some truth in your words, but why this happen? What is
the difference between two physical addresses?


When a bridge/switch does not know which port to direct a unicast packet
it will broadcast it to all ports, except the port it was received.
It might be that the mac-address of user1 in scenario.2 is unknown on
the layer2 network (i.e. user1 is no longer logged on) and therefore the
bridges/switches will broadcast all traffic destined to user1's ip
address. If user2's network card has naive OS, rotten drivers, a cheesy
NIC and/or the NIC is simply put in promiscuous mode then the network
stack would receive the packets and process them since the IP addresses
match.

[ Now coincidentally since the router always believes that user1 is
always reachable, even when user1 is offline, then when someone floods
user1 while user1 is offline then you'd have broadcast storm on your
network. ]

Tip: If you want the effect of each user having their own physical lan
(so they can't steal each others ip addresses) you need to segregate
them in a manner that effectively gives each user a physical lan. Vlans
might help, if done correctly.


Unfortunately, this can't be done in our case.

That is very unfortunate. I have been in that position and the problems
never end until everyone has their own virtual network. You have my
sympathy.

--
Sten Daniel Soersdal
_______________________________________________
freebsd-isp@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isp
To unsubscribe, send any mail to "freebsd-isp-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Ethernet issue: works one way but not another
    ... packets transmitted, 5 packets received, 0% packet loss ... (This is when connected directly to internet through ... FBSD, I have been working with BSDI at the isp I work for for the last ... As for my network topology, I have an internal network that goes ...
    (freebsd-questions)
  • Re: Update: UDP 770 Potential Worm
    ... > the network immediately after the 'attack', ... were no packets indicating some form of replication. ... I noticed that the UDP ... > of the UDP datagrams is the IP address of the proxy? ...
    (Incidents)
  • Re: IDSIPS that can handle one Gig
    ... especially with 64-byte UDP packets. ... There are plenty of network IPS's ... IDS/IPS devices through use of fragments. ... Find out quickly and easily by testing it with real-world attacks from ...
    (Focus-IDS)
  • Re: iptables and dhcp
    ... > the same physical network segment as the firewall and the remote DHCP ... You used INPUT and not FORWARD chain ... # This target allows packets to be marked in the mangle table ...
    (comp.os.linux.networking)
  • Re: Update: UDP 770 Potential Worm
    ... > were no packets indicating some form of replication. ... > my capture was limited due to the switched ... to see if the problem occurs on the test network, ... The proxy had already been isolated from the ...
    (Incidents)