Check Point's New Software Blade Licensing Model Architecture

Background

With the R70 release of Check Points security gateway and management platform imminent, the venerable security vendor has seized the opportunity to make changes to its licensing model. The beloved UTM and Power software product lines are being gradually replaced with what they are referring to as the Check Point Software Blade Architecture. So what is it?

Lets start with a little history. Check Point's Security Gateways (aka firewalls) have always been feature rich, supporting many different functions (SSL VPN, Remote Access VPN, Site to Site VPN, Firewall, NAT, IPS, Software Acceleration, QoS, Web Application Firewall, Dynamic Routing, Clustering... the list goes on). Because of this, the Check Point license enforcement mechanism is equally rich and flexible (i.e. cp.macro* plus the associated code) which allows the vendor to create a myriad of licenses. For example, the software infrastructure is available to license things from the Database Revision Control feature of the GUI to the support for NAT on the Gateway, although Check Point license these features, and always have, as part of the SmartCenter and Gateway respectively.

This new architecture allows the most important of the many features are represented by a conceptual component called a Software Blade with each different type of Blade offering a different feature. The software blades are portable amongst security gateways so for example, if you have a gateway that has changed roles from a perimeter device to an internal device, and no longer terminates VPNs, you can remove it's VPN software blade and place it into another gateway much in the same way as you can move a hardware blade from one chassis into another. The metaphor is a good one.


Gateway Software Blades - Giving your Gateway it's Security Features

There are Software Blades available which will activate the following features:

Firewall, VPN, IPS, Acceleration & Clustering, Advanced Networking, Anti-Virus, Anti-Spam, VoIP Security and finally Web Security. Although the Acceleration & Clustering and Advanced Networking Software Blades appear to be new, they are in fact a combination of four existing features:

Picture 17


If you work for a Check Point reseller you should immediately recognize most if not all of the features mentioned so far. The Firewall, VPN & IPS come from the core gateway product since the Express/Pro line, the Anti-Virus, Anti-Spam & URL Filtering are taken from the VPN-1 UTM product, and the Acceleration and Advanced networking from the Power product. As a result they are all neatly split up into to separate parts that can be licensed in a piece meal fashion. The customer can buy what he needs, not more, not less.

You can see an example of a Check Point Gateway fitted with all of the currently available Software Blades. The only Software Blade that might make you look twice is the VoIP Security. It's not my place to explain this however you should review the R70 'What's New' document when it's available.

Picture 5



Gateway Containers - Giving the Gateway it's Multi-Core support and User Count

What's also vital to point out is the gateway container. You need to purchase a Container before any of the blades become useful, and it's the container that governs how many cores and how many users the gateway will support. Some containers come bundled with many Software Blades, some come with only the Firewall Blade.

They are available in the following varieties:

SG80x - 8 cores / unlimited Users

SG40x - 4 cores / unlimited Users

SG20x - 2 cores / 500 Users

SG10x - 1 core / 25 users

I'll discuss what the x stands for in a moment, however, we can see that the first number simply reflects the number of cores and users the gateway will support.

You'll notice less variety in the available user counts versus the previous price list. 1 core container will only support up to 25 users and the2 core container, 500 users. This is a major change. We've lost the granularity of the old licenses which were available in brackets of 25, 50, 100, 250, 500 & of course Unlimited.


Putting it all together!

Now lets talk about the pre-populated, Containers. These are effectively bundles of a Container and the most commonly used Software Blades and closely resemble the products from the previous UTM/Power price list.

Picture 11

We clearly understand what the first number in the new Software Blade Gateway Bundles indicates, but what about the third number (the second number is always zero - so we'll skip it here)? Well, it simply tells us the initial number of software blades that are included in the bundle. In essence the bundles are made up of one or more of three different components which I've grouped under somewhat familiar names. (Remind yourself that the ACCL Blade includes SecureXL and ClusterXL, and the ADN Blade includes QoS and Dynamic Routing).



A picture is worth a thousands words:

Picture 14


Firstly we can see that the x06 at the top provides the same features as the previous VPN-1 UTM product but it's only available as a the single core/25 user SG106. We've no matching product in the 2xx, 4xx & 8xx series. This in my mind makes sense, as it omits the SecureXL Acceleration feature (included in the ACCEL blade) which could not accelerate UTM inspected traffic so the customer is unlikely to need it. In addition, a 25 user site would not need to scale it's gateway performance using a Load Sharing Cluster (again included in the ACCL blade); a High Availability Cluster would suffice, and so the omission of the ACCEL blade does the product line no harm.

Moving up, we've got the x05 (as a SG205 in this in this example). This is, feature wise, a VPN-1 Power product with the addition of Dynamic Routing (SecurePlatform Pro) and ClusterXL Load Sharing as part of the ACCEL and ADN blades.

Second to last, we've got the x07 which is the equivalent of the 'fully loaded' VPN-1 UTM/Power product but again with the addition of Dynamic Routing and ClusterXL Load Sharing included in the ADN and ACCL respectively.

Last but not least is another x05 this time in 8 core U user SG805 variety. This is the high performance FW/VPN/IPS gateway including SecureXL software acceleration, and 8 cores of packet processing wonderment! Again, 800 series is limited, this time to only the x05. I believe this makes sense as an 8 Core Gateway with no SecureXL Acceleration does not optimize the potential of the machine as a gateway. (In fact, the usefulness of the SXL feature depends on traffic mix, and the use of the IPS and 'UTM' features).

What's unclear at the time of writing is whether or not a blade from a bundled product can be removed from the container or not. If you have the answer, put it in the comments!


Roll Your Own (Firewall)!

Whilst the Gateway Bundles are great, they might give you more feature than you actually want. If this is the case you are able to create a completely customized gateway with only the feature your need for your business starting off with a x01 container as below.

This addresses one of the major pain points for user buying Check Point software. You might have heard it before: "I don't want to pay for features that I am not using!". With the previous price list, even the most inexpensive gateway was bundled with VPN and IPS features which put off the customer who only wants a firewall.

Essentially you have three steps in building your own bespoke Security Gateway:

1. Choose the number of cores and users you wish the gateway to support.

2. Choose your Software Blades.

3. Make your purchase.


Now lets look at an example. Yes, it's story time!

Picture 16

Here we have a Gateway that is going to be placed on the perimeter of a 300 user office and it'll run on a lovely new HP quad core box. We've already got a stand-alone IPS product from Check Point, and have decided that we don't need the Security Gateways IPS feature. Also there is another device terminating VPN connections so we'll not need this in the gateway either. Rather than waste cash on features we won't use, we purchase a SG401 container which only includes a Firewall Software Blade and provides support for our quad-core box.

After the Gateway was put in place maintenance on our URL filtering and Anti-Spam solution expired, so we purchased the ASPM and URLF blades to provide this feature on the gateway.

A year later, the CPU on the gateway was beginning to top out at 70%. After taking a look at the traffic, it was apparent that database replication was taking place through the Gateway and pushing the CPU% up. The ACCL blade was then purchased to provide SecureXL traffic acceleration. This brought the CPU down nicely.

Loss of Granularity in User Count

The user count change primarily makes the licensing easier to understand. In fact, the Software Blade concept in general is an improvement as there are a smaller number of licenses to choose from which removes a lot of confusion when putting together a solution. However, when we look at some of the lower user count licenses, for example the VPN-1 UTM 100 we find that there is no comparable Software Blade product. The closest is the SG106, which matches the features completely, but this is double the price of the VPN-1 UTM 100 and supports only 50 users.

Another example of the low end licenses loosing out is the VPN-1 Power 50. Here we have the SG103 that looks to be match. It has the same user count, core count, FW, VPN, and IPS feature, and is the same price. But the new SG103 drops the QoS and the SXL feature. If you wanted to add these features you would have to add the ACCL (Acceleration & Clustering) Blade and the ADN (Advanced Networking) Blade at $1,500 each. Bringing the total price up to $7,000 from $4,000.

Now, I don't think these cost rise on a few of the low-end products is intentional, I believe it's simply a side effect of the simplification of the licensing, something that all Check Point customers and partners have been hoping for. And if we look at the UTM-1 product line, we find that there are cost effective replacements for the smaller licenses in a hardware package which benefits the customer in that they need not purchase an Intel server to run the Check Point software.


A few Punchy Points

Here we'll briefly summarize the key changes between the old and new price list. It will not provide a complete differential, but will point you towards some of the changes that jumped out at us.

- ClusterXL (needed for Load Sharing Clusters) is less expensive: is now $1,500 as part of the Clustering & Acceleration blade. Previously $3,000 or $6,000 users per gateway. Also includes SecureXL which was previously $6,000.

- SecurePlatform Pro bundled with QoS for more value: was $1,500 for only dynamic routing. Is now $1,500 BUT includes both QoS and dynamic routing as part of the Advanced Networking Blade.

- Web Intelligence now sold as a Software Blade. No longer sold per protected server. Is now $1,500 regardless. Previously $5,000 for three protected servers, $10,000 for 10 protected servers, and $20,000 for Unlimited protected servers.

- SmartCenter UTM 5 site now the SM1003. BUT licensed based on gateways. Assuming clusters of two gateways, the product is identical.Was $10,000 is now $9,000.

- New SmartCenter (SM2500) for 25 gateways. Appears to be regular SmartCenter plus SmartView Monitor, SmartProvisioning (new R70 feature!), & IPS Event Analysis. No UTM/Power SmartCenter to compare this to.

- SmartCenter Power Unlimited is now more expensive as the SMU007. Was $22,000 is now $27,000. Appears to be missing SmartMap (my gut tells me it's been collapsed into one of the other blades, time will tell). SmartPortal is no longer included, and is a separate Software Blade. IPS Event Analysis & SmartProvisioning has been added however. Still includes SmartDirectory, SmartView Monitor (now part of the Monitoring Blade), and of course SmartView Tracker, SmartDashboard, & SmartUpdate (as part of Provisioning).

- Customer Logging Module appears to have become more expensive. Previously $1,000 now $5,000 as the SM1001. Only supports logging from 10 gateways also rather than the Unlimited as previously.




Summary

In this blog entry we took a brief look at Check Point's Software Blade Architecture and how it effects the purchasing of their software Security Gateway product line. Key points are as follows:

Container: Gives us the User Count, Core Count, and the Firewall feature

The containers remove the need for separate Multi-Core licenses (one less SKU on the pricelist!), and also take care of user count they are the basic foundation of a security gateway. They enable the Security Blades to be user count agnostic.

The x01 Firewall-only Containers keep the cost of the basic gateway low and give users what they've been asking for: a gateway that does only firewalling at a reasonable price (for a four core/unlimited user gateway the SG401 is $12,500 versus $16,000 for the U2 Power on the previous list).

Software Blades: Gives us the flexibility we need

With the Software Blades priced at $1,500 regardless of gateway user count or core count (excluding the Services Blades), adding additional features to your gateway is now as simple and a one line purchase order. I cannot overstate this. Previously it would involve either a 'trade in' or 'functionality upgrade' process, which was complex, and time consuming for both end user, reseller and Check Point themselves.

The portability of the software blades between gateways also means that you can 'drag' a feature from one gateway and 'drop' it on another, allowing customers to move an unused gateway feature to a gateway that really needs it, saving on cost.


Conclusion

All in all this is an improvement. Whilst the Management components seem to have had the biggest price changes, these may well provide good ROI to the customer in the form of the new Management features in R70. I can't wait to see them. The gateway changes appears to offer customers good value and the flexibility they've been requesting for a long while. I personally hope that this model stays with us for some time.

Subnet calculator in Checkpoint

Should you ever forget intricacies of the subnetting Checkpoint bothered not to strip subnetting calculator from their Splat – ipcalc, so use it and litter not your memory with useless info.
Given subnet show the 1st Ip (network) :

# ipcalc -n 192.168.34.45/27
NETWORK=192.168.34.32

Given subnet show the last IP (broadcast) :

# ipcalc -b 192.168.34.45/27
BROADCAST=192.168.34.63

Be careful though what you feed as no proof-reading is done by the ipcalc :

# ipcalc -b 192.168.34.45/33
BROADCAST=255.255.255.255

snmp-map in ASA is for passing through traffic only

I don’t know who to blame – me for not being attentive or Cisco documentation for being vague, but when I read about snmp-map inspection that allows you to block selectively by SNMP version I decided it was the way to protect ASA itself from such queries. And only with the help of Netpro forum at Cisco.com did I learn that this feature is designed to inspect the SNMP traffic that passes THROUGH the ASA and not destined to the ASA itself.
So if you want to limit what version of SNMP ASA will use to answer queries , use usual snmp-server host …
For those who do want to block passing through the ASA SNMP of say version 1 and 2c , here is how:

Louvre(config)# snmp-map no-v1or2-here
deny version 1
deny version 2c

Now define with access-list what traffic to inspect, you may use specific IPs or just general SNMP ports – udp 161 and 162:

Louvre# sh run access-list no-v3
access-list no-v1or2-here extended permit udp any any eq snmptrap
access-list no-v1or2-here extended permit udp any any eq snmp

Bind ACL to class-map:

Louvre(config)# class-map snmp-block-v2or1
match access-list no-v1or2-here

Use the class-map in policy map with enabling snmp-map inspection :

Louvre(config)# policy-map no-snmp-v2or1
class snmp-block-v2or1
inspect snmp no-v1or2-here

And finally apply the policy map on some interface

Louvre(config)# service-policy no-snmp-v2or1interface outside

Number of connected SecureClient or Secureremote users

Here is how to see number of connected to the gateway users. Nothing special/interesting and I am sure somewhere in the SecureKnowledgeBase it is to be found but with recent licensing improvements people ask a lot about that.

# fw tab -t userc_users -s
HOST NAME ID #VALS #PEAK #SLINKS
localhost userc_users 73 1 3 0

Forcing NICs on SecurePlatform full/half duplex or 10/100/1000 Mbps using ethtool

Network interfaces cards (NICs) on SecurePlatform are configured to auto-negotiate link speed and duplex settings with the device to which they are physically connected to. If a NIC interface is unable to auto-negotiate with the device, it is necessary to hard code the settings.
Solution:

In expert mode, use the 'ethtool' to hard code link speed and duplex settings of network interfacesNICs.

Note: Per the IEEE specification, gigabit speed cannot be forced. It can only be auto-negotiated.

Quick command syntax:

ethtool -s DEVNAME speed 10|100|1000 duplex full|half autoneg off|on

Example:


  • ethtool -s eth0 speed 100 duplex full autoneg off
    (Will force eth0 interface to 100 MB link speed, full duplex).


  • ethtool -s eth0 speed 100 duplex half
    (Will force eth0 interface to 100 MB link speed, half duplex).


  • ethtool -s eth0 autoneg on
    (Will force eth0 interface to auto-negotiate).


  • ethtool -s eth0 autoneg off
    (Will force eth0 interface auto-negotiate off).


Commands can be put at the end of the /etc/rc.local startup script, to survive reboot.

m Wake on multicast messages.
b Wake on broadcast messages.
a Wake on ARP.
g Wake on MagicPacket(tm).
s Enable SecureOn(tm) password for MagicPacket(tm).
d Disable (wake on nothing). This option clears all previous options.

sopass xx:yy:zz:aa:bb:cc
(Set SecureOn(tm) password. Argument to this option must be 6 bytes in ethernet MAC hex format (xx:yy:zz:aa:bb:cc).

msglvl N
(Set driver message level. Meanings differ per driver).


Full options of command:
Example:

ethtool -s ethX [speed 10|100|1000] [duplex half|full] [port tp|aui|bnc|mii] [autoneg on|off] [phyad N] [xcvr internal|external]
[wol p|u|m|b|a|g|s|d...] [sopass xx:yy:zz:aa:bb:cc] [msglvl N]


OPTIONS

-s
Allows changing some or all settings of the specified Ethernet device; options only apply if -s is specified.

ethX
Device Name

speed 10|100|1000
Sets speed in Mbps; ethtool with a single argument will show supported device speeds.

duplex half|full
Sets full- or half-duplex mode.

port tp|aui|bnc|mii
Selects device port.

autoneg on|off
Specifies whether or not autonegotiation is enabled.

phyad N
Physical address

xcvr internal|external
Selects transceiver type; currently only internal and external can be specified.

wol p|u|m|b|a|g|s|d...
Sets Wake-on-LAN options; not all devices support this. The Argument to this option is a string of characters specifying the options to enable.


p Wake on physically activity.
u Wake on unicast messages.

Creating a Virtual Cisco Switch

White Paper: Creating a Virtual Cisco Switch:

Many people who work in my field of expertise sell, install, or support end point security software that used 802.1x to provide Network Admission Control (NAC) features. Dot1x, as I'll call it, is a great technology that enables switch ports to be disabled, or to be reconfigured, according to the security posture of the machine that plugs into it. For example, a foolish individual brings in their own virus riddled laptop into the company, our NAC software detects that it's not a company owned machine and connects the machine to a quarantine VLAN so all the nasty bugs can't damage our important servers.

However, one of the big downsides of dot1x is that to carry out demonstrations or to get to know it as a technology can be hard as you need a real switch. You can't really turn up to a meeting with a Cisco 3750 under your arm. Primary you look like an idiot, but more importantly you might catch your nice shiny suite jackets on one of the mounting ears. Ouch.

And now the solution! Whilst VMware (and VirtualBox - try it!) allowed the consultant to leave his servers at home, GNS3 allows us to leave our switches at home too! GNS3 is a open-source graphical network simulator that provides a front end for Dynamips (a Cisco device emulator - amazing work) and pemu (a PIX device emulator based on qemu). Once, you've downloaded it, installed it, and added a real Cisco IOS or PIX image (you must source these your self*) you boot up a virtual machine of the device you wish to use.

So that is our use case.

This white paper will focus on setting up the Virtual Cisco Swith. In a later paper, I'll then show you how to add dot1x to it. But that can wait for the time being. Lets get on with the basics.


Preparation

Before you begin, please ensure you have downloaded and installed GNS3 and pointed it to IOS images for the 3745 and 1700 router. You should also set the IdlePC values for both the 3745 and 1700 devices to stop them from eating all of your host CPU%. I'll not detail how to do this as there is much help available elsewhere (hint: setting idlePC value is as simple as booting the router, waiting for it to finish booting and become idle, right clicking on the router and saying 'IdlePC'. Then trying different values until your host CPU settles down from 100%).

I will not send you IOS images.

Once you are at this point pictured below do continue!

Picture 2.small

Currently GNS3 is limited to Cisco 1700, 2600, 2691, 3600, 3700, 7200 series routers. Yep. That's right there are no switch listed. But fear not!

The Cisco 3745 router is a great piece of kit. By default, it's a standard Cisco router, with the capability to host many WAN interfaces. However! It also has the ability to host an EtherSwitch module which turns the chassis into a layer 3 switch. Luckily, the writers of dynamips emulated this hardware for us too. All we need to do to make a switch is to load up a 3745 with a couple of NM-16ESW modules.


Heavy, noisy, costly, and non-portable in hardware

09186a008082ec53_guest-Cisco_2600_Series_Multiservice_Platforms-us-Product_Data_Sheet-en_7-2.jpg


Easy in Software! Take it where-ever you go!Setting Up the 3745

Lets get our hands dirty!

Drag a Cisco 3740 device into the field, right click it to configure it, and add an NM-16ESW module. Right click it and say 'Start' then right click it and say 'Console'. Watch in amazement as your device boots! Say 'no' to the kind offer to run through the initial configuration and continue to read below.

The rest of the configuration is as you would expect with one caveat. I'll mention it here. When you carry out a 'wr' command on a real 3745 the config is saved along with the contents of the NRVAM. However, when using GNS3, only the configuration is saved. The result? Any configuration that is not included when you execute 'Router# show run' will be lost between GNS3 sessions.

So far, the only thing I've noticed this affecting is the configuration you add through the enable command Router# vlan database. Do read on!


Create the VLAN

Ok, lets set up some VLANs! It is this configuration that is not saved between GNS3 sessions. Do a 'Router# show run' you will see it's nowhere to be seen. As a work around I just paste it in each time I boot up the device. Not pretty. I'm sure there is a better way.

Adding VLANs.small


Configure the VLAN interface

We do nothing more than create the VLAN and give it 'no' IP address. After all, we don't want to route between VLANs so we don't need an IP address.

Bring up VLAN 101.small


Configure the physical interfaces

Here I did the normal sort of configuration you'd do on any old Catalyst. It's worth noting here that I was lazy (efficient?) and used the 'interface range' command as to configure all the interfaces in one go. A life saver. Also note that the ports I configured we're those on the EtherSwitch. The ports hosted directly by the 3475 router (FastEthernet 0/0 & FastEthernet 0/1) are routed ports and do not accept the 'switchport' command. On a real 3745, these would be used for WAN connections (say, an external Satellite link that presents as ethernet) and cannot be added to a VLAN. Any traffic from a non-EtherSwitch interface you wish to go to an EtherSwitch interface must be routed through the CPU. You cannot switch between the non-EtherSwitch and EtherSwitch interfaces.

Configuring Switch Ports.small


Check the interface status

At this point were showing that the VLAN interface and the switch ports are down (see no asterisk by any of them).

Interfaces down.small


This is because we need to 'connect cables' to them to bring the link lights up. The easiest way to do this in GNS3 is using a Ethernet Switch. Make sure to connect an ethernet switches to FastEthernet 1/0 and FastEthernet 1/1.

Connect the Interfaces 1.smallConnect the Interfaces 2.small


Tickle the interfaces

Now the cables are in we have to tickle the interfaces in order for them to recognise the 'virtual' cables. Normally you wouldn't need to, but it's a virtual world after all so we have to make an allowance or two ;)


Tickle the Interfaces.small

Note that the VLAN line protocol came up too... If you find that the VLAN line protocol won't come up, a possible cause is a missing vlan database. Run 'Router#vlan database' and make sure your VLANs are configured there.


Testing!

Ok, you're going to need to plug hosts into those ethernet switches. Now you have some choice:

Choice 1: For the advanced IT guy, who know their network-fu:

Create two virtual machines using VMware or Virtual Box or w-h-a-t e-v-e-r you like

Put both Virtual Machines on the same subnet (VM1: 10.0.0.1/24 VM2: 10.0.0.2/24)

Crate two TAP interfaces in the OS - tap1 and tap2

Connect VM1's network interface onto tap1

Connect VM2's network interface onto tap 2

Now in GNS, replace the ethernet switches with Connectivity Clouds, call them cloud1 and cloud2

Configure cloud1 to connect to tap1

Configure cloud2 to connect to tap2

Now, we've configured this:

VM1 <=> tap1 <=> cloud1 <=> fa 1/0 SWITCH fa 1/1 <=> cloud2 <=> tap2 <=> VM2

On VM1 ping VM2

It works?! REJOICE! You just mastered some cool virtual networking that will serve you well! I hope you had a moment!

OR

Oh, it didn't work? Oh well.... read on


Choice 2: For the regular chaps, who's 'fu' is only slightly lacking, but who soon will become masters

Create two 1700 series routers (ANY router will do, I used 1700 as they boot up fast in emulation). Cable both f0 interfaces to the switches as shown.

Test Diagram.small

Run though the initial set up and give f0 the appropriate IP address as shown.

R2R1


Now, ping from R2 to R1 and rejoice!

Sucess.small

Now to check you didn't do something silly... check the Mac Address Table of your switch...

Mac-Address-Table

You should see that after you run the ping the switch adds the two MAC addresses to it's forwarding table. You now have your software switch! All that's left to do is feel bad if you weren't man enough to setup the tap interfaces and cheer yourself up with a Mountain Dew, Pepsi Cola, or sugar water of your choice (caffeine optional).


Summary

So at this point, you have a fully working Cisco Switch in software ready to use for your demo's, testing, or education! No more dragging that 6500 chassis onto the tube. Your back will thank you :)

Next time we'll look at doing something a little more fun with our switch. I am hoping for some dot1x excitement or perhaps some spanning tree between multiple switches. But for now at least, it's time for bed.



Notes

Saving your Lab

Most users of GNS3 realise at some point that saving their project can be done in a few ways.

1 - Typing 'save' in the Dynagen Console

2 - Clicking File => Export

3 - Clicking File => Save

I would highly recommend that you use method 3. But by default option three only saves the network topology (the pretty picture) not your router configs, even though I tick the 'Save nvrams and other disk files'. Perhaps this is only my setup, but I'll document it here anyway.

When you create your new GNS3 project ensure you click 'Export router configuration files'.

Picture 2

Then when you do a File => Save, ensure that see the below lines. You can even check the .cfg files to be sure that configs are complete.

Picture 1


Device boots up with an empty config

I've found a few times, that I've started GNS3 up, started my routers and found that they have a completely blank config (it boots to the initial configuration dialogue). I've found to fix this you should close down GNS3 (and ANY running Dynamips processes - use task manager) and then clean out the projects working directory, the global working directory (you will find these in the GNS3 preferences) and your profiles 'temp' folder.

It's a clumsy fix. I've not spent a great deal of time looking into it. Perhaps there is a better way. I'm not sure.

Start up GNS3 and you should find that all is well!