Taylor Dawson: Good morning, good afternoon, good evening, everyone. Thanks for joining today's webinar: From Tech Debt to Trusted Automation: Smarter, Safer Firewall Management. My name is Taylor Dawson. I'm a Senior Solutions Consultant here at Network to Code, and I’ll be your emcee for today's session. 

We've got an exciting lineup of content, and some seriously sharp folks ready to show you how Nautobot and IP Fabric can transform how your teams manage firewall rules with less friction and a whole lot more automation. So sit back, grab that second coffee, and let's get into it.  

Joining me today are two fantastic individuals you'll hear from shortly. First, we have my colleague Federico Olivieri, who's also a Solutions Engineer at Network to Code, and someone who lives and breathes automation day in and day out. Representing IP Fabric, we've got Daren Fulwell, Field CTO and long-time advocate for getting things done smarter across the network. 

Each of us will bring different pieces of the story today—from platform synergy to deep dive demonstrations. So let's get started. What we're going to cover today is a quick introduction to who Network to Code and IP Fabric are, how we’re better together in providing this solution, and we’ll break down the firewall provisioning process specifically. We’ll start with where most teams are today, and then look at where you can go tomorrow. You'll get a look at Nautobot’s application ecosystem and a few apps, specifically the Application Dictionary and the Firewall App, and a demonstration of how both of these work. Of course, we’ll also show how this pairs well with IP Fabric’s solution, and a demonstration of that technology as well. We’ll wrap up with some time for Q&A at the end. 

Before we get into it, a couple of housekeeping items. Do not forget to use the reaction button at the bottom—we’d love to see what everyone is finding interesting and what you're excited to hear about throughout today’s webinar. Please hit those reactions and be interactive throughout the session. We also encourage you to ask questions, so please use the Q&A section at the bottom to submit any. The chat has been disabled for this webinar. Federico, Daren, and I will be happy to answer your questions throughout the session, as well as at the end during our dedicated Q&A time. 

So, let’s talk about who Network to Code and IP Fabric are, and why we’re better together. To start, if you are new to us at Network to Code, here’s the TL;DR: We help enterprise network teams reduce manual work, increase reliability, and scale with confidence through automation. Our mission is quite simple: we want to build a world where every network is fully automated. To do that, we offer a full stack of services, from strategic and advisory services, to professional services, all the way to managed and support services. And of course, with those services we have our platform of choice: Nautobot, the open-source automation platform purpose-built for networking. To talk a little more about IP Fabric, I'm going to hand the mic over to Daren so he can introduce himself. 

Daren Fulwell: Thanks for that, Taylor. IP Fabric was really born out of a need to fill the gaps left by conventional processes in network operations. It’s about managing and understanding real networks—the ones with lots of different vendors, technologies, both old and new, across cloud and on-premises environments—and how they all work together to deliver applications. More often than not, that responsibility has been left to individuals, who must ensure documentation is up to date and accurately reflects the state of the network from the last time it was touched. That, of course, leads to gaps in coverage, inaccuracy, and multiple desperately out-of-date references. 

What IP Fabric does to solve that problem is automatically discover the entire network end to end and model it as data. But then it goes much further by using that model to verify that the network is behaving the way you expect it to. 

Taylor D.: So let's talk about why Network to Code and IP Fabric are such a strong match. At Network to Code, we’re all about enabling intent-based automation. That means making sure the network behaves the way the business expects it to. To do that, we need reliable, real-time insight into the network's actual state.  

That’s exactly where IP Fabric comes in. They give us that assurance layer—visibility, validation, and verification across the network—just like Daren described. When you combine a source of truth with IP Fabric’s dynamic insights, you get a feedback loop that enables safe and scalable automation. And to break that down, Daren, let me hand it back over to you. 

Daren F.: Thanks, Taylor. From the IP Fabric side, our goal is very simple. We're providing deep visibility and end-to-end assurance to validate that the network matches the intent you just described. Whether you're troubleshooting, validating a change, or preparing to push a firewall rule, we make it easy to understand the real-time state of your network and the behavior that results from it. Nautobot, of course, brings the context—application definitions, ownership, and business logic. When you bring these two platforms together, you not only see what's going on, but you can take confident action quickly. Instead of guesswork, you have the ability to make data-driven decisions to drive automation. 

We’ve been working together for some time now—not just coming up with theory, but actively developing practical use cases for automation across our customers. These range from ensuring the single source of truth stays synchronized with the network state, to providing access to rich network data through chatbots, and validating changes across the whole network, like we’ll see in today’s use case. And there are plenty more in the pipeline, which we’ll come to later. 

Taylor D.: Fantastic. Together, we are shifting from reactive operations to proactive automation. And it's not just about scripting tasks—it's about building a trusted, closed-loop system that continuously learns, always verifies, and constantly adapts with our ever-changing networks. That’s the foundation we’re setting today, and the reason this partnership just makes sense. So, let's dive into it. 

Daren F.: Let’s start by digging deeper into what IP Fabric does and how it’s valuable in modern network operations, especially in the context of automation. Here’s a quick overview of IP Fabric as a platform. We gather data directly from network nodes using CLI or API. That includes inventory data, configuration, state, and policy. The clever part is where we analyze it to build topology and a model that reflects how everything is interconnected—whether it's on-prem infrastructure or cloud. Our analytics layer runs rules over that model, using our own expertise and external datasets. We’ve developed dozens of standard checks that automatically run as part of our discovery process. 

The results can be consumed directly by users via our UI or through our extensive API. We integrate with all kinds of operational tooling to deliver that intelligence to whoever needs it. This is really where our collaboration with Network to Code shines. A great early example was the Nautobot Chatbot, which lets you pull data directly from our API and present it in Slack or other chat platforms. We’ll see more examples like that today. 

To give you an idea of what this enables, here’s an example: because we don’t just have the data but an understanding of the network, we can perform lookups against our data model—like this path between two hosts. It passes through switches, routers, firewalls, and whatever else lies between. There are equal-cost paths here and various types of network nodes. Because IP Fabric understands how these systems work, we can effectively trace the path—do a packet walk through our data model. 

You’ll notice two red boxes in the middle—these are firewalls. While we do have a path from one end to the other, the firewall policies are blocking the traffic. So, we need to make a change that modifies the behavior of those firewalls. After making the change, we run another snapshot in IP Fabric, and now when we look up that same path, those firewalls that were red are now green. That green represents the updated policy, which now allows the traffic to pass. We’re seeing that as a visual diagram here, but we can also pull that same data via API—and that capability is key to the use case we’ll be exploring next. We'll see it in action shortly. 

I'll hand it over to Federico now so he can introduce Nautobot. 

Federico Olivieri: Thank you, Daren, and thank you, Taylor. Alongside IP Fabric, Nautobot is the other key component of this solution. So let’s have a brief overview. For those unfamiliar, Nautobot is an open-source product developed and sponsored by Network to Code. It serves a dual purpose—it functions both as a network source of truth and as an automation engine. 

With its opinionated data model, Nautobot allows you to define the intended state of your infrastructure via its source of truth capabilities. Additionally, thanks to a rich ecosystem of application extensions, Nautobot can perform automated tasks such as configuration, compliance, and service quality maintenance, just to name a few—and, as we’ll see today, firewall rule provisioning. 

Nautobot is available in two forms: self-managed or as a SaaS application. Based on what we’ve discussed so far, if we look at the network automation diagram, we can see that Nautobot and IP Fabric sit at the core layer of the architecture, covering the most critical aspects of infrastructure automation. 

Let’s move on and dive into today’s topic. To better appreciate the benefits our solution brings, let’s first review today’s typical workflow and roles for a firewall request. We have two main personas: the requester, or product owner, whose sole responsibility is to raise firewall requests; and the engineer, who is responsible for implementing those requests, maintaining up-to-date firewall configurations, and managing related configuration data such as IPAM. The engineer is also ultimately accountable for security audits. 

Let’s explore each step in today’s workflow. The product owner needs connectivity between two applications. They pull data related to those applications from one or more sources of record, such as a CSV file or IPAM. Then, they raise a firewall request via an ITSM platform. Based on the information provided in the ticket, the engineer performs path discovery to identify potential firewalls between the two applications. Due to vendor-specific syntax, OS version differences, and discovery file discrepancies, the engineer may need to write different types of configurations. The configuration is then pushed to the devices and verified. Once verified, the ticket is updated. 

This step is one of the major pain points in the workflow, as issues frequently arise—such as misconfigurations, outdated IPs due to unreliable sources of record, or incorrect firewalls being identified. Lastly, and most importantly, as you can see, there is no automation involved in any of the steps outlined so far. 

Now let’s explore how we envision what we call “next-gen firewall rule automation.” The first step is to rebalance responsibilities between the two personas. To achieve this, we need to abstract the definition of an application away from IP addresses and instead use a human-readable string representation of the application. The best way to understand this is by thinking of an FQDN. For example, when you type “google.com,” you don’t know—or need to know—what IP address is behind it. You just know that “google.com” is the search engine you’re looking for. 

If we define a set of applications and assign each to a specific product owner, that product owner can then raise and manage firewall requests based on the applications they are responsible for, without needing to worry about low-level network details like IP addresses. The network engineer, on the other hand, has the knowledge of the business logic and security requirements for each application. This allows them to enforce those requirements when defining applications and assigning them to one or more product owners. At the same time, the engineer is also responsible for defining interoperability between applications owned by different product owners. 

We achieve this through the onboarding process. As mentioned earlier, IP Fabric provides visibility into firewall configurations and their components, such as APIs, VRFs, VLANs, and more. Using Nautobot’s SSOT (Single Source of Truth) app—more on this later—it’s possible to onboard all necessary data from IP Fabric into Nautobot. This onboarding process enables the definition of applications and allows enforcement of security constraints required by regulatory policies. 

Once applications are defined, they can be assigned to individual product owners. As mentioned earlier, the network engineer can identify interoperability rules between applications. For example, consider an e-commerce web front-end application that is allowed to communicate with its back-end database, but not with an HR database. These kinds of policies can be clearly enforced through the defined application relationships. 

Let’s review the pieces of the workflow again to better appreciate what comes next. Note that there are no automation steps involved. 

Now let’s walk through each step of the new workflow we’re proposing. The first step remains the same: the product owner needs connectivity between applications. However, this time the product owner interacts directly with Nautobot, and as we mentioned earlier, uses meaningful text strings instead of IP addresses to model the required connectivity between applications. 

Thanks to application-to-endpoint mapping, Nautobot translates the application names into their corresponding endpoints. Once that’s done, Nautobot passes those endpoints to IP Fabric, which then discovers the firewalls along the path between the two applications. IP Fabric builds the list of Access Rule Objects (AROs), and Nautobot then generates the required configuration. 

An important note here: Nautobot is completely vendor agnostic. So, if multiple firewall vendors are identified along the path, Nautobot will generate the appropriate configuration for each of them. Once the configurations are created, they are pushed to the device controller or directly to the device. As a final step, IP Fabric takes a new snapshot of the network and runs a post-check to verify success. 

As you can see, this workflow is heavily—if not fully—automated, freeing engineers from time-consuming operational tasks. We understand, however, that in certain situations, a manual review of new intended firewall rules may still be necessary. Since Nautobot is API-centric, it can be easily integrated with ITSM applications, as represented here by the purple squares. Before making changes to a firewall, Nautobot can generate a ticket containing all necessary details for the engineer to review and approve the change request. Once approved, the workflow can continue automatically via webhooks, completing the process I described in the previous slides. 

Because Nautobot supports cloud provider modeling, and IP Fabric can discover application paths both on-premises and in the cloud, this proposed workflow is fully capable of supporting hybrid infrastructure. 

So let’s dive into the components that make up this workflow. The first layer we look at is the abstraction layer, which is handled by the Nautobot Application Dictionary. This is the Application View in Nautobot, where all applications are defined and assigned to specific owners. As you can see on the right side, there are four applications belonging to three different owners. If I’m part of the network team, and these applications are allowed to be interoperable, I can raise requests involving applications that are not directly under my ownership. 

This view is where application dependencies are defined. As a product owner, I interact only with this form, where I can easily model the connectivity between applications. I don’t need to know anything about IP addresses or firewalls. I get a clear overview of my application dependencies and can manage them with just a few clicks. 

In the Application Service View, I can see the mapping between applications and IPAM. By leveraging Nautobot’s IPAM and DCI components, I can define which server an application is running on, as well as the connected subnet or IP addresses. By also specifying the application’s port and protocol, the full tuple is completed, providing the necessary data to eventually convert application dependencies into firewall policies. 

We conclude the Application Dictionary section by looking at the Application Details View, where all relevant information is listed—such as components, services, and inbound and outbound dependencies. 

The second-to-last Nautobot layer in this solution is the Firewall Model Hub. Let’s take another look at the previous slide, where application dependencies are defined in the Application Dictionary, to better understand how they map to policies. Now, let’s see how Nautobot translates those abstracted application dependencies into vendor-agnostic policy rules, including necessary objects such as address groups and service groups. 

So enough theory—let’s move to the demo. On the Nautobot homepage, we go to the Application Dictionary section and look at our test app, which has two services: SSH and web. The first check is to show the API integration with IP Fabric by running a dry run. We ask IP Fabric if the rules for those applications are already configured in the necessary firewalls. IP Fabric returns the firewall names and a response indicating that those applications are denied along the path. 

Daren F.: What you’re seeing here is the IP Fabric UI performing the same check. This is the path lookup process. You can be as specific as you want in terms of Layer 4 information. Once submitted, we can show you the result. Here, the path is blocked at two firewalls. We can see the security policy blocking the first one, and then we move to the second firewall and reveal its policy too. If you were doing this manually, you’d often fix the first firewall without realizing that others also need changes. But by showing the whole path, we can identify all necessary policy changes in one go. 

Federico O.: Here, we’re going to share the same view on our Panorama Controller. There are currently no policies defined for the application in the Application Dictionary. As a second step, since the applications have been defined but not yet converted into policies, we can confirm there are no firewall policies in Nautobot for those applications either. 

What we’re going to do now is rerun the same job, but this time in write mode. We’re asking Nautobot to create the policies needed to allow those two applications. Again, through an API, IP Fabric responds with the list of devices. Since we see there are denials, as before, we proceed to create the necessary rules. 

From there, we can see the policies are created in Nautobot. So, from the definition of the application in the Application Dictionary, there’s now a conversion into vendor-specific network policies within the Firewall app. Now, through integration with the Panorama Controller, we’re going to write these policies. Through the API, we connect to the Panorama Controller and push our configuration. 

As you can now see in the controller, the rules have been created. Going back to Nautobot, we commit the changes—a required step for the type of firewall we’ve been using in this demo. Again, using the SSOT integration with this controller, we write the changes. Finally, we move into the post-check phase, where we ask IP Fabric to verify if the configuration was successful by triggering a new snapshot of the network through the API. 

Daren F.: And there you can see, as we go back into IP Fabric’s UI, the snapshot has started and is progressing through. It's pulling the latest information about those two firewalls. The updated configurations are now being inserted into IP Fabric’s model, and once that completes, we can go ahead and run the checks again. There’s the snapshot. As we move to the path lookup, we can see—just catching up here—that from the data we've captured, the rules have been deployed, and IP Fabric has successfully pulled that information from the devices. 

Federico O.: Just to reiterate, now we are going to rerun the same job, and this time we’ll see that there are no rules denying our flows. As shown here, the three applications are now allowed, and there are zero deny rules found. 

Daren F.: Now we’ll look at that in IP Fabric. Here's our path lookup that we ran earlier with the three ports. When we submit that, our firewalls are now green. That indicates the security policy is now allowing the traffic to flow. At the bottom, we can see those policies have been deployed on both the left-hand and right-hand firewalls. As we click through to examine the details, there you go—that’s the firewall policy. The yellow highlight indicates the specific rule that has been enumerated and is currently passing traffic. 

Just to complete the picture: all three rules have been deployed. You can see the two tools working together in harmony. It’s a really great example of the automation ecosystem providing new ways of operating your network, and it’s something we at IP Fabric and Network to Code are deeply committed to moving forward. 

Some examples of what we’re looking at now include enhancing telemetry—not just by pulling data from individual devices—but by applying deeper network understanding to ensure the relevance of that data is clear. We’re also enriching ServiceNow workflows with operational data without requiring manual effort or copy-pasting into tickets. Watch this space—there will definitely be more webinars to follow this one. 

Taylor D.: Fantastic. Thank you so much, Federico and Daren. Let’s open it up now for some Q&A. Earlier, we ran a poll—thank you to everyone who participated. If we want to bring up those results again, we certainly can. It looked like there was a wide distribution of responses. We saw an even balance among those using general automation tools for various use cases, those relying on homegrown approaches they inherited or built themselves, and others who are still in the planning or decision-making phase when it comes to selecting automation tools for their teams and organizations. 

Daren F.: Sorry, Taylor—didn’t mean to jump in there. But I think the beauty of those responses is that everyone is clearly at a different stage in their automation journey. A use case like the one we’ve just shown works for all of these groups. Whether you’ve got pre-built solutions or are integrating with existing approaches, there are lots of different paths forward depending on where you are in that journey. 

Taylor D.: Thank you again to everyone who participated in the poll. There were also quite a few great questions submitted in the Q&A, so let’s unpack a few of those quickly. 

I see one that’s probably best for you, Daren. The question is: Is it possible to see firewall rule hit counters within IP Fabric? 

Daren F.: That’s a great question. We don’t gather live data directly from network devices—that typically comes from your monitoring tools. However, as we’ve shown, we can evaluate and enumerate the security policies once they’ve been deployed. So, the short answer is no, we don’t collect hit counters. The longer answer is that we provide alternative ways to assess which rules are useful and necessary in your deployment. Thanks for the question. 

Taylor D.: Another question I see is specific to Nautobot, so I’ll take this one. The question is: Does Nautobot ensure there are no duplicate rules—specifically firewall rules? 

The answer is yes. When you pair the Application Dictionary with the Nautobot Firewall Model application, you gain access to a data validation engine that checks for rule duplication and ensures there’s no harmful overlap. That validation is built into the platform. 

Another good one here: Can this solution be integrated with any ITSM, or just ServiceNow? 

Fantastic question—thanks for asking. The answer is: yes, it can be integrated with any ITSM. As Federico mentioned earlier, this is a vendor-agnostic solution. Whether you’re using ServiceNow, Jira, or another specialized ticketing system, we can integrate with it successfully. 

Let’s see what else we’ve got here... Is it possible to index my policy rules? Within Nautobot, you can certainly apply an index and a weight to your policies and rules. That’s a built-in function of the platform. If there’s anything specific you’d like to add from the IP Fabric side, Daren, I’m happy to open the floor to you. 

Daren F.: Not specifically on that topic, but I did notice a couple of other questions coming in. One was about whether IP Fabric applies security zones and routing to the simulation of the path. The short answer is yes. We take into account deployed policies—whether it’s load balancing, PBR, or other mechanisms—as part of the modeling. I also saw another question about extending this to include URL lists and application awareness. 

The firewall model in Nautobot is very sophisticated. I’ll let Fed cover that in more detail, but from the IP Fabric perspective, we do evaluate URL filtering and application rules as part of our path simulation as well. 

Fed, any thoughts from the Nautobot side? 

Federico O.: Nothing to add—you guys have already covered everything well. 

Taylor D.: Great. I see another question here: Can I see the impact of the change on the target device before it’s implemented? Federico, would you like to take that one? 

Federico O.: Sure. If you remember from one of the workflows we presented, there’s a manual review process. Instead of pushing directly to the device or controller, Nautobot can integrate with an ITSM platform to raise a ticket. That allows for manual review and approval before the workflow continues to completion. 

What we showed was an ideal workflow, but of course it should be structured based on your specific needs. If you prefer to perform the review within Nautobot itself or another system instead of the ITSM, that’s absolutely possible too. 

Daren F.: I can add something from our side as well. From a pathing perspective, IP Fabric validates both the forwarding path and the security policy. This allows you to see every point where policy is enforced. So even if a policy is currently blocking traffic, we can show you the full potential path. That way, you can evaluate the impact of a change—like switching a deny rule to permit—before actually applying it. You get a clear view of what the traffic path would look like after the change. 

Taylor D.: Awesome. And now I’m seeing more questions trickle in. A couple of them ask: Are Check Point firewalls supported? Are legacy firewalls compatible with Nautobot? 

We’ve addressed this a few times, but it’s worth reiterating: yes. This is a vendor-agnostic solution. Whether you're using legacy firewalls, more modern platforms, or centralized managers like Panorama or FortiManager, they can all be integrated with this solution successfully. 

Great questions across the board. I really appreciate everyone’s interest and the lively Q&A session. I'm just scanning now to see if we missed any remaining questions. If there’s anything we haven’t answered, we’ll be happy to follow up directly after the webinar. 

 If you do have any questions that we weren’t able to answer live, we’re more than happy to connect with you afterward. We can dive deeper into the solution from a technical perspective or discuss how it applies to your specific business and use case. 

With that, let’s move on from the Q&A and go through a quick recap of what we covered today. 

So again, we kicked things off with an introduction to Network to Code and IP Fabric, and explored why this partnership makes so much sense. We walked through the current firewall provisioning process and showed how we’re helping teams evolve toward a more automated, intent-driven future. After that, you saw a deep dive into the Nautobot ecosystem and the IP Fabric solution during our joint demonstration. And finally, we wrapped up with a great poll and a live Q&A session to answer your questions. 

I want to thank everyone for taking the time to join us today. If you’re walking away thinking, “I need to see this in my environment,” good news—we’re happy to set up a tailored demo for you and your team. 

So for anyone interested in a deeper discussion or demo, just reach out to us at networktocode.com or ipfabric.io, and we’ll take care of the rest. 

On behalf of Federico, Daren, and myself—thank you again, and we hope to see you in a future session.