Avoid Denial of Service situation when using private vlan?

[Apachez-]

Private vlan (PVLAN) is often the recommended method to separate clients from each other at L2 level yet still be able to use a shared L3 network (to avoid ip address slacking which otherwise would happen if you use one vlan per client along with one /30 per client).

This way the clients have the same default gateway and the same netmask.

To setup private vlans in a A5820 the command to use is "isolate-user-vlan" where you define which vlan is the promiscious one and which vlans are the secondary vlans.

Like this:

isolate-user-vlan 100 secondary 101-148

In this case vlan 101-148 will have one client each (vlan101 is on int 1, vlan 102 is on int2 ... vlan 148 is on int48) and vlan 100 is the promiscious one which all secondary vlans can speak to. The defgw ip is setup in "int vlan100".

In order for the clients to be able to send L3 traffic to each other one need to enable proxy-arp/local-proxy-arp at the "int vlan100" interface.

From the client point of view when the client sends an "arp whohas <defgw>" it will only be whatever sits on vlan100 who will be able to respond (normally just "int vlan100"). Any L2 traffic wont reach the other client vlans.

So far so good...

However... what happens with traffic that arrives through the uplink with dstip=client1?

The A5820 will from int vlan100 send out a "arp whohas <client1>" to all secondary vlans (because I dont want the administrative downside of having to manually register clients mac addresses) in order to find out where this client is located.

In this case client2 could reply back to the defgw and say "I am <client1>, here is my macaddress" as a classic arp poisoning.

Sure, one could setup a VACL so only the ip address which should exist on lets say vlan101 is allowed through (so the client2 cannot get the packets which is for client1) - but this would still make it a Denial of Service situation for client1 (because A5820 will as long as there is traffic continue to incorrectly send the packets down to client2 mac address at vlan102 instead of the correct one which would be vlan101).

What Im thinking of is if there is a possibility to force the routing so that packets for a specific dstip is always sent out on a specific vlan even if this vlan doesnt have an ipaddress set?

That is something like this:

ip route-static 192.168.0.1 vlan101

ip route-static 192.168.0.2 vlan102

...

ip route-static 192.168.0.48 vlan148

I noticed this in the manual which I assume means that the above thought wont work:

"

interface-type interface-number: Specifies the output interface by its type and number. If the output interface is a broadcast interface, such as a VLAN interface, the next hop address must be specified.

"

Or is the fix simply to just (note that vlan101-148 doesnt have any ip addresses configured as SVI):

ip route-static 192.168.0.1 vlan101 192.168.0.1

ip route-static 192.168.0.2 vlan102 192.168.0.2

...

ip route-static 192.168.0.48 vlan148 192.168.0.48

Or are there some other options available to fix this issue?

In this particular case the clients will be using static ip addresses and no 802.1x or such.

[paulgear]

I don't have anything to add to this, but I'm also interested in the answer...

[Peter_Debruyne]

I would recommend to use the right technology for the right purpose.

In this case, it seems you have 2 requirements:

1/ users cannot change their IP address and should not be allowed network access if they do

2/ users cannot communicate with each other

For requirement 1/ I would recommend the arp/ip control, available with the ARP attack protection and IP Source guard features (easiest to combine with dhcp snooping, otherwise you need to manually make IP/MAC bindings in the switch config). You can also use DHCP static reservations to move the admin to the DHCP server and keep the switch config simple. This will handle the IP spoofing concerns you have.

For requirement 2/ you can use :

* the isolated vlans feature

* mac-forced forwarding (MFF), which will filter all client ARP requests and replace them with the ARP record of the central L3 switch (where you can define ACLs and control what is/is not allowed between the clients)

(works for L3 traffic, but would still allow L2 protocols between the hosts).

* a simple ACL (packet-filter) on the user device switch ports, where you can block all local subnet access and permit other traffic (works for L3 traffic, but would still allow L2 protocols between the hosts).

See device configuration guides for detailed configurations.

[Apachez-]

Sadly there doesnt seem to exist the proper technology in comware to handle this situation (unless Im missing something?).

What I have is a topology such as:

ISP <-> A5820 <-> A5120 <-> Client(s)

where the A5820 acts as a L3-device (default gateway for the client(s)) and A5120 acts as a L2-device.

The ip assignments are static (no DHCP involved). This gives that I can have a port ACL on the A5120 for srcip filtering (fulfilling BCP38).

That is the A5820 is configured as:

#
interface Vlan-interface100
 description SW1
 ip address 192.168.1.254 255.255.255.0
 local-proxy-arp enable
#

which is then tagged (trunk) over to the A5120 which is setup as:

#
interface GigabitEthernet1/0/1
 description 01_CLIENTXX
 port link-mode bridge
 port access vlan 100
 undo jumboframe enable

 packet-filter 3101 inbound

 stp disable
 undo ndp enable
 undo lldp enable
 lldp admin-status disable
 mac-address max-mac-count 10
 port-isolate enable
#

...

#
interface GigabitEthernet1/0/48
 description 48_CLIENTXX
 port link-mode bridge
 port access vlan 100
 undo jumboframe enable
 packet-filter 3148 inbound

 stp disable
 undo ndp enable
 undo lldp enable
 lldp admin-status disable
 mac-address max-mac-count 10
 port-isolate enable
#

The above gives a classic protected vlan setup (or with comware lingo port-isolation).

From the client point of view the above means that client1 (sitting in gi 1/0/1) wont see whatever L2-traffic (such as arp replies) client 48 (sitting in gi 1/0/48) is sending/generating. It will only see whatever int vlan100 at A5820 sends (hence the "local-proxy-arp enable" which gives that client1 can send packets to client48 through int vlan100).

The problem is the arp-traffic in the other direction - that is when int vlan100 asks "who has 192.168.1.48?" and client1 will answer "I do!!!".

Even if I apply ACLs (so client1 will only get packets with dstip=192.168.1.1) this will still invoke a denial of service situation for client48 (because int vlan100 at A5820 incorrectly thinks the mac-address for 192.168.1.48 is the mac address of client1 instead of the correct one client48).

Digging through the manual I found the "arp filter source" command, however that only seems to protect the gateway and not act as a arp-filter on which srcip would be allowed in the arp-message from a specific interface:

"

Use the arp filter source command to configure ARP packet filtering based on the gateway’s IP address on the current port. After that, ARP packets with the gateway’s IP address as the sender IP address are considered invalid and discarded.

"

There is also a "arp filter binding" but in order to use that I must know the mac-address of the client (and I dont want the administrative burden och manually updating the ip<->mac bindings every day with a couple of hundred clients).

What I would need is a command such as the "arp filter source" but with the reverse meaning. Instead of which sender-ip (in the arp-message) should be dropped it would be which sender-ip is allowed.

Something like (pseudo-code):

interface GigabitEthernet1/0/1
 arp allowed sender-ip 192.168.1.1
#

...

#
interface GigabitEthernet1/0/48
 arp allowed sender-ip 192.168.1.48

#

This would block any arp poison attempt from rogue client without having to run DHCP to fix this nor having to manually keep an updated list of ip<->mac bindings.

So any suggestions on how to do this in A5120 would be great :-)

[Peter_Debruyne]

I see, that is more challenging indeed ;)

I do not have a direct fix, but I think this article might help you (maybe you had it already):

http://www.h3c.com/portal/products___solutions/technology/ipv4___ipv6_services/technology_white_paper/200908/643656_57_0.htm#_Toc236717025

One of the "easy to implement" features on the gateway which seems to fit in your question is the ARP Active Ack:

Whenever the GW receives new ARP info, it will check if there is an existing ARP entry for this IP.

If there is (it means the new ARP is trying to spoof the original IP), the gw will first send a unicast ARP to the original MAC/IP.

If that original host is still online, it will reply, so the GW will not update the ARP record with the new ARP info.

If the host would be offline, it will update the entry.

This seems like an administratively simple to maintain system, which still ensures the ARP table cannot be just overruled with a gratuituous ARP. (so this would be applied to the 5820 L3 GW)

Let me know what you think,

Peter.

[Apachez-]

Thanks for the tip unfortunately that wont work either because:

1) If the attacker is faster to respond to the arp whohas than the victim then this function (arp active ack) would still put the victim in a denial of service situation.

2) If the client replace equipment (like connect another computer but with the same ip because this static ip is the only allowed on this interface) it will have to wait up to 25min before the connection can be used (ARP timeout is 25min in comware).

Because "arp filter source" is about which senderip to block (instead of which senderip to allow) - unless contacting HP regarding for an enhancement request, would it be possible to lets say use a traffic classifier or something to "manually" filter which senderip would be allowed from which physical interface?

That is a traffic classifier that only looks at ethertype 0x0806 (ARP) and if the senderip matches the particular interface (inbound) the packet would be allowed otherwise it would be dropped.

[Peter_Debruyne]

I agree that it is not bulletproof.

for 1/ I agree

for 2/ this would not be a real issue, since a replacement of a PC will result in a no-reply on the active-ack request, at which point the ARP table would be updated with the new record immediately.

Why don't you include dot1x on the endpoints, so any non-managed system would simply not get network access ?

At that point the risk would already be reduced to the managed systems only.

And I would still keep the DHCP fixed leases option open. I know this is more admin work, but using static IP means admin work anyway. Once you have DHCP in place, normal ARP protection will auto learn the MAC/IP Bindings and will do what you want it to do (and you get the IP spoof protection options on top of that).

DHCP operations can be scripted/automated quite easily to help in the admin process of allocating mac/ip as reservations.

If this is not possible, you will need to make your call to HP and ask for an ARP-ACL feature I guess...