Hi!

Need support for proxy_arp_pvlan ("/proc/sys/net/ipv4/conf/<interface name>/proxy_arp_pvlan" in linux).

proxy_arp_pvlan - BOOLEAN
Private VLAN proxy arp.
Basically allow proxy arp replies back to the same interface
(from which the ARP request/solicitation was received).

This is done to support (ethernet) switch features, like RFC
3069, where the individual ports are NOT allowed to
communicate with each other, but they are allowed to talk to
the upstream router. As described in RFC 3069, it is possible
to allow these hosts to communicate through the upstream
router by proxy_arp'ing. Don't need to be used together with
proxy_arp.

This technology is known by different names:
In RFC 3069 it is called VLAN Aggregation.
Cisco and Allied Telesyn call it Private VLAN.
Hewlett-Packard call it Source-Port filtering or port-isolation.
Ericsson call it MAC-Forced Forwarding (RFC Draft).

FYI I just requested this as well.

You can already do this with... Well... Proxy arp and ip firewall or with split horizon bridging.

You can already do this with... Well... Proxy arp and ip firewall or with split horizon bridging.

Not exactly...

Split Horizon Bridging is primarily to prevent L2 loops, not provide client isolation. Currently Proxy-ARP will not answer back with the MAC address of the bridge interface if the destination IP/MAC are on the same interface. This is what the proxy-arp-pvlan feature is needed for.

Using Split Horizon Bridging you would be able to prevent PortA from directly reaching PortB, but you would not be able to force all IP traffic between the two via the Bridge Interface as Proxy-ARP will only respond back with the bridge interfaces MAC for ARP entries on OTHER interfaces, not on the same bridge interface. For this you need proxy-arp-pvlan

I have requested this from Mikrotik support today, it is available in the kernel that RouterOS 6 uses, and would be a minor change. I am hopeful they will approve the feature and we will be able to

BUT, the OP wanted to have devices on the same subnet talk to upstream router but not each-other. split horizon bridging will accomplish this easily. Just put all customer ports in horizon 1 and the upstream port in horizon 0 and you are in business.

I do see the difference in what you were asking for though.

If there's an RFC for it and the kernel currently used by RouterOS supports it, I'm not sure why it wouldn't be done. It just... makes sense.

Please get this implemented.

For Mikrotik reference this request is in tickets:

Ticket#2014070866000074
Ticket#2014070866000047

OK.

So I got a response from support. They are considering adding this feature.

In the meantime, you can achieve a similar result using bridge nat.

I have tried several variations of the arp-reply nat trick -- no progress whatsoever.

After MITM interceptions to make sure a reply was being sent, every recent version of R/OS was failing to actually send the reply.

Code: Select all

/interface bridge nat
add chain=dstnat mac-protocol=arp action=arp-reply to-arp-reply-mac-address=<bridge1-MAC>

/interface bridge filter
add chain=forward comment="Accept ARP" in-bridge=bridge1 mac-protocol=arp out-bridge=bridge1
add action=drop chain=forward comment="Drop everything" in-bridge=bridge1 out-bridge=bridge1

/ip firewall filter
add chain=output protocol=icmp icmp-options=5 out-interface=bridge1 action=drop

As of 6.38rc7 there is a new ARP reply option on bridges "local-proxy-arp"

This allows for PVLAN type functionality on Mikrotik bridges.