PVLANs provide Layer 2 isolation between ports within a VLAN. They split a broadcast domain into multiple discrete broadcast subdomains by creating secondary VLANs inside a primary VLAN. Ports within the same community VLAN can communicate with each other. Ports within an isolated VLAN can communicate only with a single uplink port.
Ethernet LANs are vulnerable to attacks such as address spoofing (forging) and Layer 2 denial of service (DoS) attacks on network devices. Port security features help protect the access ports on the services gateway against loss of information and productivity that can result from such attacks.
The following features are NOT supported on PVLANs by Junos switches with support for the ELS configuration style:
DHCP security features (DHCP snooping, dynamic ARP inspection, IP source guard)
Egress VLAN firewall filters
Ethernet ring protection (ERP)
Flexible VLAN tagging
Global MAC statistics
Integrated routing and bridging (IRB) interface
Multicast snooping or IGMP snooping
Multi chassis link aggregation groups (MC-LAGs)
Port mirroring
Q-in-Q tunneling
VLAN Spanning Tree Protocol (VSTP)
Voice over IP (VoIP)
This article explains how to enable port security with the help of firewall filters on ELS devices. Below is a solution to prevent ARP learning on PVLAN using filters.
In order to achieve a level of port security on ELS supported devices, we can tweak with policies to ensure some of the functionalities that are restricted on these devices become achievable.
Consider a scenario where there are two dedicated servers hosting services for clients and connected to one EX3400 switch. The default gateway for servers is configured for EX3400. In such a scenario, there is a possibility that without appropriate port security features, clients will be able to hijack addresses with much ease. In this case, our goals would be to:
Isolate servers at layer 2, considering both servers in the same subnet.
A client must be able to see only the MAC address of the gateway in its ARP-table.
The following configuration snippet prevents ARP learning within hosts of the same VLAN:
Apply the filter on host interfaces in order to prevent ARP learning.
[edit firewall family ethernet-switching] + filter arp-restrict { + term arp-permit { + from { + source-mac-address { + c0:20:d1:12:00:01/48; + } + destination-mac-address { + ff:ff:ff:ff:ff:ff/48; + } + } + then accept; + } + term arp-discard { + from { + destination-mac-address { + ff:ff:ff:ff:ff:ff/48; + } + } + then discard; + } + term accept-any { + then accept; + } + } + filter server1 { + term server1 { + from { + source-mac-address { + 00:20:00:13:00:11/48; + } + source-prefix-list { + server1; + } + } + then accept; + } + term ARP { + from { + ether-type arp; + } + then accept; + } + term discard { + then { + discard; + log; + } + } + } + filter server2 { + term server2 { + from { + source-mac-address { + 00:20:00:30:00:12/48; + } + source-prefix-list { + server2; + } + } + then accept; + } + term ARP { + from { + ether-type arp; + } + then accept; + } + term discard { + then { + discard; + log; + } + } + }
ARP table before the filter was applied:
[root@server1~]# arp -an ? (192.69.12.3) at 00:20:00:30:00:12 [ether] on eth0 ? (192.69.12.1) at c0:20:d1:12:00:01 [ether] on eth0
ARP table after the filter was applied:
Note: The client is able to see only MAC address of the gateway in the ARP table
[root@server1~]# arp -an ? (192.69.12.3) at c0:20:d1:12:00:01 [ether] on eth0 ? (192.69.12.1) at c0:20:d1:12:00:01 [ether] on eth0
Example configuration snippet relevant to the above-explained scenario:
root@switch# show vlans test vlan-id 20; l3-interface irb.20; forwarding-options { dhcp-security { no-dhcp-snooping; arp-inspection; group port-sec { interface ge-0/0/0.0 { static-ip 192.69.12.2 mac 00:20:00:13:00:11; } interface ge-0/0/1.0 { static-ip 192.69.12.3 mac 00:20:00:30:00:12; } } } } {master:0}[edit] root@switch# show interfaces irb unit 20 proxy-arp unrestricted; family inet { no-redirects; no-neighbor-learn; address 192.69.12.1/29 { arp 192.69.12.2 l2-interface ge-0/0/0.0 mac 00:20:00:13:00:11; arp 192.69.12.3 l2-interface ge-0/0/1.0 mac 00:20:00:30:00:12; } } [edit interfaces ge-0/0/0 unit 0 family ethernet-switching] + filter { + input server1; + output arp-restrict; + } [edit interfaces ge-0/0/1 unit 0 family ethernet-switching] + filter { + input server2; + output arp-restrict; + } [edit policy-options] prefix-list SNMP-access { ... } + prefix-list server1 { + 192.69.12.2/32; + } + prefix-list server2 { + 192.69.12.3/32; + } [edit firewall family ethernet-switching] + filter arp-restrict { + term arp-permit { + from { + source-mac-address { + c0:20:d1:12:00:01/48; + } + destination-mac-address { + ff:ff:ff:ff:ff:ff/48; + } + } + then accept; + } + term arp-discard { + from { + destination-mac-address { + ff:ff:ff:ff:ff:ff/48; + } + } + then discard; + } + term accept-any { + then accept; + } + } + filter server1 { + term server1 { + from { + source-mac-address { + 00:20:00:13:00:11/48; + } + source-prefix-list { + server1; + } + } + then accept; + } + term ARP { + from { + ether-type arp; + } + then accept; + } + term discard { + then { + discard; + log; + } + } + } + filter server2 { + term server2 { + from { + source-mac-address { + 00:20:00:30:00:12/48; + } + source-prefix-list { + server2; + } + } + then accept; + } + term ARP { + from { + ether-type arp; + } + then accept; + } + term discard { + then { + discard; + log; + } + } + }
2021-03-26: Article reviewed for accuracy, no changes required; article accurate and valid