01-10-2025 09:44 AM
Hello. My company that I work for currently does not use IPv6 in our organization. We currently only use IPv4. During our annual penetration test last month, the pentesters were able to reply to IPv6 DHCPv6 requests to successfully hijack DNS for workstations within the local domain. They recommended to enable DHCPv6 Guard on switch.
Would this configuration work ? Would I need to set up a IPv6 server policy even thought we do not use Ipv6?
This is the config in a test lab on the access swithes. Vlan 20 and 21 are DHCP user Vlan's.
DHCP Guard
1.ipv6 dhcp guard policy RCH-DHCP-CLIENT
2. device-role client
3. vlan config 20
4. ipv6 dhcp guard attach-policy DHCP-CLIENT
5. vlan config 21
6. ipv6 dhcp guard attach-policy DHCP-CLIENT
RA Guard
ipv6 nd raguard policy DHCP-HOST
device role host
vlan config 20
ipv6 nd raguard attach-policy DHCP-HOST
vlan config 21
ipv6 nd raguard attach-policy DHCP-HOST
Solved! Go to Solution.
01-10-2025 11:57 AM
Hello @cooperrocks78
Your proposed configuration for enabling DHCPv6 Guard and RA Guard on the access switches is appropriate and should work effectively to mitigate the issue identified during your penetration test...
The configuration helps prevent unauthorized or rogue DHCPv6 servers and malicious RA messages within your network, even though your organization does not actively use IPv6.
The DHCPv6 Guard feature ensures that only trusted DHCPv6 servers can respond to DHCPv6 requests, blocking rogue devices from hijacking DNS or other network services. Your configuration includes the creation of a DHCPv6 Guard policy (RCH-DHCP-CLIENT) with the role set to client. By attaching this policy to VLANs 20 and 21, you effectively block any unauthorized DHCPv6 server responses in these VLANs.
Also, since your organization does not use IPv6, you do not need to configure a server policy or define trusted DHCPv6 servers. The current setup protects your network by enforcing the client-only policy and ensures no rogue devices can respond to DHCPv6 requests. This approach is sufficient to address the penetration testers' findings without introducing unnecessary complexity.
As concerned RA Guard, it prevents unauthorized or malicious RA messages, which can be used to perform man-in-the-middle attacks or redirect traffic to rogue gateways. The DHCP-GOST policy in your configuration specifies the host device role and blocks RAs in VLANs 20 and 21 by attaching the RA Guard policy, seems to be good. This ensures that endpoints within these VLANs cannot be influenced by rogue RAs or incorrect IPv6 routing information...
01-12-2025 06:26 AM
Yes, your configuration would help mitigate the issue by preventing rogue IPv6 DHCP servers from assigning malicious settings to clients. Enabling DHCPv6 Guard ensures that only trusted devices can respond to DHCPv6 requests, blocking unauthorized DHCP servers. Similarly, enabling RA Guard prevents malicious devices from sending rogue Router Advertisement (RA) messages that can disrupt IPv6 operations.
Even though your organization doesn't currently use IPv6, it's good practice to implement these safeguards because IPv6 is enabled by default on many devices, and attackers can exploit it in dual-stack environments. You don't need to set up an IPv6 server policy if you're not actively using IPv6, as the guard features work by blocking untrusted traffic rather than requiring a functioning IPv6 server. Ensure proper testing to validate the configuration in your environment.
01-10-2025 11:57 AM
Hello @cooperrocks78
Your proposed configuration for enabling DHCPv6 Guard and RA Guard on the access switches is appropriate and should work effectively to mitigate the issue identified during your penetration test...
The configuration helps prevent unauthorized or rogue DHCPv6 servers and malicious RA messages within your network, even though your organization does not actively use IPv6.
The DHCPv6 Guard feature ensures that only trusted DHCPv6 servers can respond to DHCPv6 requests, blocking rogue devices from hijacking DNS or other network services. Your configuration includes the creation of a DHCPv6 Guard policy (RCH-DHCP-CLIENT) with the role set to client. By attaching this policy to VLANs 20 and 21, you effectively block any unauthorized DHCPv6 server responses in these VLANs.
Also, since your organization does not use IPv6, you do not need to configure a server policy or define trusted DHCPv6 servers. The current setup protects your network by enforcing the client-only policy and ensures no rogue devices can respond to DHCPv6 requests. This approach is sufficient to address the penetration testers' findings without introducing unnecessary complexity.
As concerned RA Guard, it prevents unauthorized or malicious RA messages, which can be used to perform man-in-the-middle attacks or redirect traffic to rogue gateways. The DHCP-GOST policy in your configuration specifies the host device role and blocks RAs in VLANs 20 and 21 by attaching the RA Guard policy, seems to be good. This ensures that endpoints within these VLANs cannot be influenced by rogue RAs or incorrect IPv6 routing information...
01-12-2025 06:26 AM
Yes, your configuration would help mitigate the issue by preventing rogue IPv6 DHCP servers from assigning malicious settings to clients. Enabling DHCPv6 Guard ensures that only trusted devices can respond to DHCPv6 requests, blocking unauthorized DHCP servers. Similarly, enabling RA Guard prevents malicious devices from sending rogue Router Advertisement (RA) messages that can disrupt IPv6 operations.
Even though your organization doesn't currently use IPv6, it's good practice to implement these safeguards because IPv6 is enabled by default on many devices, and attackers can exploit it in dual-stack environments. You don't need to set up an IPv6 server policy if you're not actively using IPv6, as the guard features work by blocking untrusted traffic rather than requiring a functioning IPv6 server. Ensure proper testing to validate the configuration in your environment.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide