Firewall rules for IPv6 targets

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Firewall rules for IPv6 targets

L1 Bithead

We are trying to implement IPv6 in our network, and as part of this deployment all our network resources should run on dual-stack (IPv4 & IPv6). Address objects Types in our firewall policy rules have been written based on IP (IP Netmask and IP Range), not with FQDN.

(Option 1) To make the same firewall policy rule be used (for Ipv4 and IPv6 targets), we need to convert each address objects into FQDN or (Option 2) we have to create a duplicate firewall policy rule with IPv6 targets or add the corresponding IPv6 address object to each firewall rules). What do you think which option we need to go with?

Thank you

4 REPLIES 4

L4 Transporter

Hello @Dereje 

 

First thinking as always in a possible and safe rollback to use ipv4, I would consider the best option to clone the rules and add the ipv6 sources and destinations.

 

Having differentiated rules allows you to have a better tracking, review in log monitoring and check the correct hits of these.

 

Regards

High Sticker

L0 Member

I suggest a combination of both with using FQDNs while still having separate security policies for IPv4 and IPv6 to allow for better visibility in your logging.

#FOSS

Cyber Elite
Cyber Elite

Hello @Dereje

 

we are currently in similar situation, however our goal is to move to IPv6 native instead of dual stack. Although, I do not think I can give you an answer whether to go with option 1 or 2, I would like to share a few points.

 

- For duplication of the rules if you have any IPv4 rule with GEO location, you will not be able to have exact the same equivalent as currently there is no support for IPv6 GEO database. There is a feature request for it: #2865.

- Watch out for User-ID mapping if your IPv4 rules are leveraging source user information and you will duplicate this setting to IPv6 rules. This part caused some delay with deployment in our case, as additional tuning, troubleshooting and testing was required.

- During migration process, we ended up with duplicating of existing IPv4 rules into IPv6, however since deployment of IPv6 apart of business reasons presented a chance of re-design of almost everything for IP addressing, routing design, policies, we aimed to duplicated only standardized policies through Panorama. All legacy local exceptions were not duplicated in an effort to declutter policies. After you enable dual stack end to end, your endpoints will in most cases prefer IPv6 over IPv4, so new IPv6 rules will likely get more hits. This might be a good chance to clean/tune up some of the policies.

 

Kind Regards

Pavel

Help the community: Like helpful comments and mark solutions.

Thank you for the response and the shared idea. We have the same idea of cloning the rule and modifying it for only v6 rule, but having thousands of rules, cloning that many rules is a daunting task unless we come up with some form of automation. 

  • 1518 Views
  • 4 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!