Milan Zapletal: Welcome everyone. My name is Milan. I'm from IP Fabric, and am a Solution Architect. And with me here is Christian.
Christian Giebner: Hello, I'm Christian, also a Solution Architect here at IP Fabric, and welcome to our webinar. Happy to show you around.
Milan Z.: Yeah. Let's get started. So, about IP Fabric very shortly. For those new to IP Fabric, think of us as creating a digital model of your entire network infrastructure. We automatically discover and map the state of every device and connection, and create context.
We also capture configuration and data across your environment, whether it's on-premises, in the cloud, or hybrid. Unlike traditional monitoring tools that only show you what's happening right now, IP Fabric gives you a complete understanding of how your network is designed, configured, and behaves.
This comprehensive visibility becomes the foundation for everything we will discuss today about security and compliance. More to say is that maybe nine out of ten CIOs lack a unified view of their infrastructure, which opens organizations up to breaches and compliance issues. And with IP Fabric, we are trying to solve this fundamental challenge.
IP Fabric transforms network security by giving you unprecedented visibility into your security posture. First, we automatically collect and analyze all your management protocol configurations—like AAA settings, SNMP community, and system configuration—giving you a complete protocol inventory for device hardening.
Think about it this way: management protocols are the ultimate gateway to your network infrastructure. Second, our platform can simulate network paths end to end, showing you exactly how traffic flows through your network, including your ACLs. We also understand the security policies that will affect the traffic, or policy-based routing rules.
This means that you can test the security before changes—before implementing them—or validate your segmentation, whether it is working as intended, and identify potential security gaps. All of this discovered data becomes intelligence that you can leverage for network hardening, finding the weak points, ensuring consistent security policies, and proving compliance with security frameworks. It becomes very standard—and easier—to achieve.
In version 7.2, which is the main focus throughout this webinar, we significantly enhanced our firewall capabilities. We now can provide detailed simulation of next-generation firewall behavior, including URL filtering rules and threat feed configurations. And this is crucial, because modern firewalls do much more than just allow or deny traffic.
Those are not just expanded ACLs—they're making complex decisions based on application awareness, URL categories, or threat intelligence. IP Fabric now collects this data directly from your firewalls and can simulate their behavior in our digital twin. We've also added support for transparent firewalls—those security devices that organizations often lose track of because they don't change IP addresses or routing by design.
In version 7.2, we also provide detailed mapping and documentation of IPsec tunnels, which are crucial for understanding how data is encrypted in secure communication channels, as is required by frameworks like ISO or regulations like DORA or NIS2.
Thank you for staying with us throughout this brief presentation. And now I would like to pass the word to Christian, who will show you some very concrete examples in the way you can achieve your goals with the current version. Thank you.
Christian G.: Many thanks, Milan. I would like to start by talking about the enhanced intent checks.
Basically, in the past, an intent check was always based on a specific table. You could select columns of the table and define specific entries as a success, or as a warning, or as an error. But sometimes this was not enough, because sometimes you had that information—"Okay, I have SNMP configured, ACL is not empty, that's great"—but just as an example, if you want to understand: on which kind of device do I have it? Or, do I have it on specific types of devices where I've added some attributes to it? It was not possible to do.
This is now doable. So, if I scroll down, as you can see, I can now select different or additional information from the device table—or, in this case, also add a device attribute.
It will match only against devices that contain the attribute I specify. Let’s say I put in "ABC," if that is the name of the attribute. Now I can say, if it contains the word "checkpoint," for example, then it will show me—or mark—only the devices with that attribute, and where the access control is not empty, as successfully configured devices.
All the others will be placed into "other" or "no category," depending on how you continue to configure your intent check. But this gives you precise freedom to really build intent checks with higher accuracy and get the data you want to have.
Milan Z.: By the way, for those who are not fully familiar with IP Fabric—what we are achieving right now is that, first, attributes are labels that you can assign to devices based on your own logic or principles within your CMDB or your organization. To be able to filter by device vendor, platform, or even operating system wasn’t possible in previous releases.
And basically, we are cross-referencing the network inventory data with any table or information about a technology that we collect in IP Fabric, and we are combining it with the intent rules. So whether you are applying specific rules just to certain categories of devices based on your labels—it's now doable.
Or whether you are applying your rules based on a specific vendor or site—that's also available now.
Christian G.: Thanks for this addition. Okay, let's now take a look at how we can visualize the IPsec tunnels. Of course, we do have a table where you can see all your IPsec tunnels, the state of your tunnel—whether it’s up or down, which encryption you are running, and all of that.
But in the past, it wasn't possible to see them in the diagram. I've chosen this diagram where you can see quite a few firewalls, and now I would like to show you how quickly and easily you can show—inside the diagram—where your IPsec tunnels are, so you can visualize them.
I'm just removing Layer 1 and Layer 2 information. I'm grouping the Layer 3 information, as it's usually condensed into one single line inside this diagram. Now I'm selecting the IPsec tunnels. I just want to see where my IPsec tunnels are. I don't care about the routing protocols, the default gateway, or any of that.
I just care about the IPsec tunnels. And when I click the submit button, it shows me: here is my IPSec environment. So I can easily spot where the interconnections are, which firewalls are using secure communication, and where the data is tunneled. I can really understand where I may need to expand my IPSec or VPN environment, or where there are tunnels that may no longer be useful—and could be removed.
Milan Z.: By the way, for those who are not familiar with the previous versions of IP Fabric, just to clarify—we already collected, in the past, information about IP tunnels and gateways. That was already present in our technology table in great detail.
What has changed now is that before 7.2, we were not creating the logical connection in the map—in the visual topologies—which we now enable in version 7.2.
Christian G.: Yep. Okay, and now let’s take a look at how we work with—or take a look at—our enhanced firewall capabilities.
In the past, if you wanted to check "Can I reach the internet using HTTPS?"—you’d enter source: any, destination: for example, the DNS of Google to simulate an IP address. Then you’d click the submit button and see the path: okay, I’m hitting the internet, the firewall is letting me pass.
Always good—but what if you have a URL filter and want to understand whether specific URLs are reachable or not?
We’ve added this functionality. Now you can work with site categories, or URLs, or domains. If I use—just as an example—this URL, and I add it to the request (without changing anything at source, destination, or protocol), I just add the URL and click submit. I get a different result.
The firewall is blocking that URL. It's not letting me pass through—even though the protocol is the same and nothing else has changed.
If I need more details, I can use the Path Inspector, which automatically shows which data we're using as source, destination, and so on—including routing information—but also which firewall rule has been hit. Clicking on it shows me the firewall rule, so I can understand what's going on and why my traffic is blocked or not.
Let’s do the test: if I change the URL to a good one and hit the submit button again, I get a different result—zooming out, I can see it's really focusing on the URL that was entered and whether it’s allowed.
I think this shows quite well how we’ve incorporated this into our solution. And of course, if you want to work with categories, you can also work with categories here.
Milan Z.: Thank you, Christian. The only thing I’d add is that in the previous versions, we could already simulate traffic from a source to a URL as a destination.
In that case, we had to be able to match the URL to a specific destination IP. But we were completely unaware of any rules that included URL filtering—and with version 7.2, that has changed.
Christian G.: Yep. Okay. Now let’s give a small sneak peek. What’s also already added to IP Fabric is the creation of manual links, which allows you to incorporate your Layer 2 filtering into our solution. Since it’s usually not easy to discover and place these devices—a transparent firewall is, by design, a transparent device—we’ve built in a feature that allows you to add these devices and links manually.
You select the device you want. As you can see, I’ve already prepared something. But just to show you quickly: you select the device, select the appropriate interface, and define whether it’s a Layer 1 or Layer 2 connection.
Once the link is created, you run your snapshot. We’ll discover the device and incorporate this link into the view. Again, I’ve already prepared it, so the link I created manually is visualized. You can now understand: okay, where is my transparency hiding?
Milan Z.: Yeah, maybe a little clarification on why this is a bit of a sneak peek. We can already discover transparent firewalls starting in version 7.2. Let me say this: transparent firewalls are always a challenging environment. They have their own goals, of course. They're IPS gateways, and they have other functions. They're essential in some places.
We have a great discovery engine, but even for us, transparent firewalls are hard to discover. They're hard to understand—especially the way they connect to other environments. If they're connected to a C-I-leaf environment, they require some IPS filtering.
We thought a long time about how to resolve that issue and how to understand what interfaces of the transparent firewalls are actually connected to our environment. We came up with the concept of creating manual links. There are two types of manual links.
One is Layer 1, which will only appear as a map connection—like a standard CDP or LLDP connection—with no real traffic functionality. The second is Layer 2 links, which will help us actually use the transparent firewalls for traffic path simulations.
That’s for the future—it will be available starting with version 7.3, which is going to be released, I would say, quite soon. From then on, you’ll be able to discover your transparent firewalls, create connections to your environment, and use them for path simulations as well, which is the ultimate goal.
Christian G.: Yeah, and I’d like to add, if there are any questions, feel free to submit them in the Q&A section.
I see a question: “Are compliance checks a point in time, or are they continuous?”
Our compliance checks are based on intent checks, and those are applied on every snapshot. So, whenever we discover a network, we gather all the data, apply the desired state of the network, and match it against the state we just collected. Then we show you where there are mismatches, where you need to improve your network to be compliant, and where you are already successfully matching the requirements of any given regulation—whether that's NIST 2, DORA, PCI—you name it.
And as you can now create even more powerful intent checks, this gives you even better detail in terms of compliance.
Milan Z.: Can IP Fabric run automated path simulations over tunnels when there are multiple sources and multiple destinations at scale?
Well, that’s a great question—thank you for that. So, the way IP Fabric operates is that you can use the GUI, of course. But there's a limit. If you're a UI user, you can only simulate one thing at a time—or open multiple tabs and simulate many things—but that doesn't scale well.
What our customers often do is leverage our API capabilities. Anything you can do in the UI in terms of simulation, data extraction, and so on, you can also do via API—and the API scales very, very well.
We’ve seen use cases where a customer wanted to test if a firewall was implemented correctly, and the test included 50—or even 200—different sources. There was one destination, and they wanted to verify that all 200 simulations traversed the firewall with the correct source and destination interfaces and used the correct policy.
They used our API for this. They simulated 200 different paths via the API and got results within a couple of minutes using our engine. So yes, API simulation can scale very well—you just need to leverage our API.
Christian G.: There’s another question: “Will there be selectable example intent checks—such as the ones you had in mind when developing this—or are we supposed to dream up how to utilize these new features ourselves?”
As we typically support you through our Customer Success team, of course we’ll assist in developing the right intent checks for your purposes.
These enhanced capabilities—especially when it comes to attributes—can’t be preconfigured because attribute-based intent checks are unique to your environment. It would be hard to create something universal upfront. But we will always support you, our customers, in enhancing what you have, using our knowledge from working with others, and showing you how and where to use these features.
You don’t have to dream them up yourself—we’ll support you in building them.
Milan Z.: Yeah, thank you. I would just add to that—the intent rules we saw in the presentations were specifically related to attributes and the capability to use attributes as an additional filter in intent checks.
However, there are already over a hundred best-practice intent rules inside IP Fabric by default. Attributes are a little special because, as Christian pointed out, they are specific to each environment. Every customer defines their attributes differently—so it's a custom thing.
What we recommend is not to try and define multiple attribute-based rules directly in the UI. Instead, we suggest creating a set of rules outside IP Fabric—in a place like Git—where you can think through your approach to programmatic compliance. From there, you can easily pick up the rules and populate all attributes and intent rules into IP Fabric via the API, using the source of your compliance program or database.
That’s what we’re promoting: that every customer first creates their own concept of compliance and rules—on paper, or in Git—and then programmatically pushes that into IP Fabric. That allows for more manageability.
Second question: “Can we define a generic router or gateway that is not supported by IP Fabric?”
Right now, we can create a manual link—which isn’t generated by discovery. So you might think we can also add devices or create virtual gateways that aren’t actually in the snapshot. But unfortunately, this is not possible right now. Possibly in the future—but not as of today. Thank you for the question.
Christian G.: There’s another one: “Are there published examples or whitepapers for using the API for mass testing of firewall rules, like you referenced earlier?”
Milan Z.: Yeah—great question, thanks. We have examples internally, based on interactions with our customers. Unfortunately, there are no whitepapers yet.
We’re happy to share that information once we formalize those scripts and ensure they don’t include any code we can’t share. Long story short, we’re really just leveraging our SDK to do that—and all documentation around our SDK is available online.
But in any case, feel free to get in touch. We’re more than happy to follow up on that. It’s not that complicated.
Okay—let me start the wrap-up, or however you want to call it. Again, thanks everyone for participating. Thanks for joining the webinar and listening. Thanks for the questions. And thanks to Christian.
Christian G.: Thank you very much. Have a nice day.
