Using Airwall: Secure Remote Access

Using Airwall: Secure Remote Access

by | 06-Jan-2021

In this blog post I would like to share the configuration I have been trying out with Airwall from Tempered Networks over the past months. Airwall is a new approach to security leveraging the HIP protocol defined in RFC7401. 

If you would like to read more about my experiences with Airwall, check out my first posts, Tampering Visibility with by Tempered and Configuring Airwall.

 

Network topology

The following topology describes how I have included the Airwall gateway in my home network. 

In this setup, I created a seperate VLAN for the untrusted VLAN that is effectively a subinterface on my FTD device. It allows traffic to the outside only. I have configured PAT to allow the necessary inbound Airwall communication ports. 

The trusted port of the Airwall gateway is directly connected to the client VLAN in my network. Why? I wanted to test out bonjour and L2 extension / forwarding too. 

Secure remote access

Probably one of the most visible use cases for Airwall is allowing secure access as if it was a VPN/SASE client allowing your users connecting securely to inside resources. And that is definitely possible with Airwall. You can leverage the gateway function to effectively connect secure (inside) hosts and networks via the secure ports.

For this use case, I want to securely allow access from my laptop to several management IP’s in my internal network, being:

  • Firepower Management Center (FMC)
  • C9800 Wireless Controller
  • My Raspberry PI with Domoticz to see real-time power consumption
  • My laser printer
  • My distribution switch (SSH)

As the gateway has its secure port to my clients VLAN, I just need to define these devices (and yes, IP scanning is possible) as local devices and add static routing for my network management. All this is configured for the specific Airwall via the Conductor (Airwalls -> Select the right Airwall). 

Add local devices to an Airwall gateway

Configure Overlay IP routing via the gateway.

I had some connectivity issues when I had my Mac conencted to the same VLAN and was not able to connect to my FMC. This is solvable by either setting a different overlay IP address on my Airwall Agents or configure PAT on the gateway. I’ve chosen the first option, and it has worked quite well. 

Now that the Airwall components have the right (local) connectivity, it is time to configure a security policy for secure access. Within Airwalls paradigm, these security policies are overlay networks. And they work very easy. Within the conductor the tab “Overlays” is where you’ll configure all overlay networks. I have created a hub-spoke overlay network with my own devices (which I grouped) as hub. Why would I do that? It means that all the other devices are spokes and I can automatically communicate with them, once I add them. 

Adding/Removing devices is like really easy. Just hit the plus and add any device you have defined in the Conductor, and that’s it. 

Once I add a device in the overlay, it can communicate with the hub. And when I am outside, or even when I’m at home, I am actually connecting to these devices via the Airwall secure network, as can be seen via the below traceroute.

In summary, I have been very satisfied with the way Airwall is working. This common use case is really easy to configure and manage. And as long as the underlay ports can communicate, it is fast and reliable. But you can do more with Airwall. One of the things from Security Field Day that got me triggered was the full programmability, which I will describe in another post. 

Configuring Airwall

Configuring Airwall

by | 27-Oct-2020

In a previous post I have already shared some information about the Airwall solution from Tempered Networks. In this blog, I will share my experiences in configuring and operating the Airwall solution. I have been running an Airwall setup to test for a number of months.

Airwall components

Before moving into the configuration aspect, let’s first describe the components of the Airwall solution.

Airwall Conductor

The conductor is the “heart” of the Airwall solution. It is the SDN controller (running on-prem or in a cloud) with which you manage all Airwall components and configure the different policies.

Airwall Agent

The airwall agent is a software component that is running on your user endpoint devices, such as your smartphone, tablet, laptop or desktop. It is effectively the client that connects to gateways and Airwall Server agents. 

Airwall Server agent

The Airwall Server agent is the software component that you can install on individual servers. You might say that it is comparable with the Airwall agent, except it runs faceless and is optimized for running on your servers. I have been running one on a virtual server I have hosted in the cloud. 

Airwall Gateway

The airwall gateway is a special component within the solution. You can use it to secure networks behind a gateway with agents. E.g., if you allow a connection from an agent to a gateway, you are able to securely connect from the agent through the gateway to multiple hosts or networks behind the gateway. The gateway comes in different flavors, a virtual machine, a cloud instance, a physical gateway for wired connections, and a phyisical gateway that connects to the unsecure networks via WiFi. The gateway is also capable of acting as a relay agent between agents that cannot communicate directly with each other, but only if you have specified and allow that communication in the conductor.  

Overlay networks

Overlay networks within Airwall are a bit different compared to the traditional overlay networks seen with VPN solutions, which is also what makes Airwall unique in its approach. An overlay network is basically a secured IP network that can be configured between agents, servers, and gateways. And the unique twist is that you can manage completely different overlay networks and configure a policy that a single agent can communicate via these different overlay networks.

My personal experience is that I initially misinterpreted overlay networks and thought of it as a single network with unique policies; it is easier to see each overlay network as a security policy that defines who can securely communicate with who at which moment in time. 

Underlay network

The underlay networks is your regular network, or the Internet. It is the insecure network via which you connect the different Airwall components. The conductor of course needs to be reachable via the underlay network.

Getting started

The team at Tempered networks was kind enough to provide me with a complete set of components to test with and try out use cases. My kit consisted of agents for my iOS devices, my laptops, 1 virtual gateway (Cloud), 2 physical gateways (one wired, one wireless), a server agent and a conductor.

Getting started with the conductor is pretty much straight forward, after running through the provisioning guide, you have the link to the conductor portal, which provides a good overview of your environment. The tab labels itself speak for itself. Now that the conductor is setup correctly, it is time to download and provision agents.

 

For the physical gateway, it was effectively the same setup. Hook a serial console to the device, configure the hostname and port for the conductor, activate the device and you can define your policies.

I used the provided download links to download an agent to my Mac and used the App-Store to download the iOS apps. Once they are downloaded, you provide the agent with a profile that contains the hostname and port to your conductor. It took me a while to figure out that I had to manually approve the license before further configuration was possible. So after you’ve configured your agent, go back to the conductor and hit the settings -> Licensing tab. Activate the just registered device and a license will be consumed. With that action, the airwall agent/gateway becomes active.

Remember, the gateway has different behavior compared to the agent with more functionality. Make sure that the communication ports you defined in the Conductor are available via the underlay networks. It took me a while to figure that out (I assumed too much routing in my mind), and once I had the PAT configured correctly, the gateway was working as expected and the agent on my mac could communicate with it. If you use NAT, you can configure the external IP address for the gateway via the conductor (auto-detect and auto-set would be great when you have dynamic outbound IP-addresses and relay on PAT). The screen shot below shows the setting for my gateway.

In my next post, I will give you a sample underlay network that I have been using very succesfull (including demos and firepower trainings) over the past months.

“Hey Juniper, How’s the security state of my network?”

“Hey Juniper, How’s the security state of my network?”

by | 10-Jun-2020

Most of us probably have asked Siri, Alexa, Google some questions and answers over the past years; Smart assistants are one of those new interactions. And honestly, not that many questions you asked were probably related to networks, were they? And yet, after hearing Juniper present at Security Field Day 3, these type of questions might in the near future become a normal way to allow you to interact with the network. Sounds like something from Star Trek, and is just science fiction? I beg to differ for a number of reasons. 

Before I dive into Juniper’s security strategy, let’s first review the current state of Artificial Intelligence (AI) and Machine Learning (ML) as a concept. To do that, I will explain what happens when you ask Siri to do something or a question like what is the date?.  

First of all, after you’ve asked the question, that audio bit (which is just a record of frequencies) is guessed into a sentence. It is a form of translation, where Machine Learning is used to do well-calculated guesses in what kind of word you tried to pronounce. And I can tell you that if English is not your native tongue, some weird word-guesses come out.

 

Once there is a digital sentence, another process is used to narrow down your digital sentence into a single pattern-matched result. This allows you to say things like “create a meeting on date X, Y or z”.
The model uses the pattern “create a meeting” for the match and the other values are stored in variables.

After a pattern has been matched, the code corresponding to that pattern is executed. The result of that code will be a string/sentence. That sentence is then being translated to audio using Text-To-Speech and read out loud to you.

This is a perfect flow for a single sentence / command /question. But many of these smart assistents start to show real issues once you start to create related questions, like you can do with a toddler.  And that is because the flow I described above does not have that much space for relaying context between flows. So most models in these smart assistents are built / designed for a single task, and if you put them in sequence, it appears as if the assistent is “smart”. But it is not (yet).

Yes, developments go fast, and I heard last year in San Jose a great story of self-learning models and also the core faults that are inside these models because of the way the models are designed and built. But that is a completely other discussion. 

But if AI/ML is not that far ahead yet, how would you then be able to ask Juniper about the security state of the network? That how is one of the things Juniper told at Security Field Day 3.

They leverage the power of AI/ML (and that is to have more answers than just a yes or now) in their security solutions for only a predefined, supervised, set of options. Juniper uses models (they call them supervised models) to analyse metadata about the flows in your network to detect malware and other anomalies in your network, just like other network and security vendors have done. Juniper has adopted AI/ML on detecting anomalies or other weird behaviour on your network. And that can help you a lot in gaining more visibility and control in your network.

Because with everything connected to the network, increased security by leveraging encryption, more data in the cloud, we as a human are reaching our limits in finding anomalies or odd behaviors by hand. A simple computer, using a properly tuned model, can find those anomalies much faster. And because that model does that, you can focus on determining whether that anomaly is really an anomaly of yet another new application on the network.

And if you would trust those reports blindly, you can of course automate actions, but personally I am always careful with those. Suppose it is the CEO’s smartphone, you might want to call the CEO first before you throw him off the network.

Personally I do believe firmly in that AI/ML can help you in your daily job in finding those odd behaviors that without them you’d never be able to spot and help you in providing a better, smoother, more stable and secure network. But you do need to keep in mind that it is still a computer that presents you information from a lot of data and that presentation will be biased.

But definitely a good thing that Juniper has started to embrace that principle across their portfolio. 
That can bring them quite a bit.

And to be able to ask Juniper about the security state of the network? That would be not that hard to implement, because JunOS has API’s from the start. Just build an application and integrate it with existing API’s for smart assistents. If you want to see a demo, just watch this video taken from a presentation where I asked Siri how many clients were connected to the network.

Swift, JSON Encoding/Decoding and subclasses

Swift, JSON Encoding/Decoding and subclasses

by | 17-Dec-2019

Over the past weeks I have been preparing for two CiscoLive Barcelona breakout sessions. In one of them I will give a brief demo and the other session where I will be covering parts of the Cisco Press book that I wrote. The preparation itself is not only about the slides, but also developing code that is to be used in the demo’s. These demo’s are built on iOS devices and run on some containers, so I have been writing that software in Swift, which is a beautiful and powerful programming language. One of my previous posts covers some principles of Swift. One really powerful feature is the easy capability to encode or decode data to the JSON format.  

If you want to have a class to be able to convert to and from a JSON format, just use the Codable protocol and you’re ready, see the code example below:

/*
 * Enumeration of supported message types. Extend this for new messages
 */
enum MessageType : Int, Codable {
    case unknown = 0            // default, unknown
    case acknowledgement = 255  // acknowledgement to message, if required
    case hello = 1              // hello, for keep alive, always followed by ack
    case sendMessage = 2        // send a unicast message to another client
    case broadcast = 3          // send a message to all connected clients
}

/*
 * Generic parent class
 * Every message has the following attributes
 * Version: To define which version we are talking about
 * Command of the message
 * client-id that sends the message
 */ unique request id, used for acknowledging, etc..
class Message : Codable, prettyPrint  {
    var version : String = "1.0"
    var msgType : MessageType = .unknown
    var clientId: String = "" // client host, generated by the server to guarantee
    var requestId: String = UUID.init().uuidString  // unique request id for this message, used in the ack
    
    // Default constructor
    // Not used cause calling super.init can override msgType value
    init() {
        // empty on purpose
    }
}
This code example defines a class message with variables for messageType (of type MessageType), requestId, which is a unique UUID string value, and a data variable which can contain any String. So let’s say I create a new message , called hello with the data “Hello there!” with the following code sample:
let msg = Message()
msg.msgType = .hello
msg.data = "Hello There!"

To convert this to JSON, this would only require a few lines of code:

let encoder = JSONEncoder()
let jsonData = try encoder.encode(msg)

The variable jsonData (of type Data) now contains a JSON-version of the earlier created message. Just to check the output, I can use the following commands to convert that data to String and output it in XCode’s Playground. 

let jsonDataAsString = String(data: jsonData, encoding: .utf8)

Suppose you would like to extend our message class with a special broadcast message, where the message can be sent to a all endpoints.. You could add an optional broadcastContent variable to the message class and create a state machine to determine when to use that value. Another alternative is to leverage the power of object-oriented programming and create a new subtype, like the following code example:

/*
 * BroadcastMessage is used to broadcast a message to all connected clients
 */
class BroadcastMessage : Message {
    // response message
    var msgContent : String = ""   // Message to broadcast   
}

			

				
				
				
				
				
So when you’d create a multicast message, like below, you’d expect that it would contain all attributes in the json file, right? Let’s check it out in Playground:

			

				
				
				
				
				
			

			

				
				
				
				
			

				
				
			

				
				
				
				
				
				
				

				

				
				
				
				
				

				
				
				
				
				
As you can see, the output does not contain all attributes of the broadcast message! It only contains the base message type class values. The msgContent variable is not included. It took me some time debugging and researching to figure out what happens. Swift bug SR-5431 and SR-4722  provide more details. Without going into those bugs, it comes down to the fact that as soon as you subclass a class that conforms to Codable, you need to override the default encode/decode methods and write your own. After some fiddling around, I have used the following code pattern to achieve that result.

			

				
				
				
				
				
				
				

					
/* Generic parent class
 * Every message has the following attributes
 * Version: To define which version we are talking about
 * Command of the message
 * client-id that sends the message
 * unique request id, used for acknowledging, etc..
 */
class Message : Codable, prettyPrint  {
    var version : String = "1.0"
    var msgType : MessageType = .unknown
    var data: String = "" // client host, generated by the server to guarantee
    var requestId: String = UUID.init().uuidString  // unique request id for this message, used in the ack
    
    private enum CodingKeys: CodingKey {
        case version, msgType, data, requestId
    }
    
    
    // Default constructor
    // Not used cause calling super.init can override msgType value
    init() {
        // empty on purpose
    }
    
    required init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: CodingKeys.self)
        version = try container.decode(String.self, forKey: .version)
        msgType = try container.decode(MessageType.self, forKey: .msgType)
        data = try container.decode(String.self, forKey: .data)
        requestId = try container.decode(String.self, forKey: .requestId)
    }
    
    public func encode(to encoder: Encoder) throws {
        var container = encoder.container(keyedBy: CodingKeys.self)
        try container.encode(version, forKey: .version)
        try container.encode(msgType, forKey: .msgType)
        try container.encode(data, forKey: .data)
        try container.encode(requestId, forKey: .requestId)
    }
}

/*
 * BroadcastMessage is used to broadcast a message to all connected clients
 */
class BroadcastMessage : Message {
    // response message
    var msgContent : String = ""   // Message to broadcast
    
    // coding keys enumeration used for JSON encoding/decoding
    private  enum CodingKeys: CodingKey {
        case msgContent
    }
    
    // set class variables
    private func initClassVars() {
        self.msgType = .broadcast
        msgContent = ""
    }
    
    // default constructor. Call the parent and set variables
    override init() {
        super.init()
        initClassVars()
    }
    
    // Constructor used to instantiate a class from JSON Data
    required init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: CodingKeys.self)
        msgContent = try container.decode(String.self, forKey: .msgContent)
        try super.init(from: decoder)
    }
    
    // Method used to encode class to JSON
    override public func encode(to encoder: Encoder) throws {
        var container = encoder.container(keyedBy: CodingKeys.self)
        try container.encode(msgContent, forKey: .msgContent)
        try super.encode(to: encoder)
    }
}


				

			

				
				
				
				
				
As you can see, when BroadcastMessage is converted to JSON, it is now correctly encoded.

			

				
				
				
				
				
			

				
				
				
				
				
I am now using the coding pattern below to achieve this functionality:


    

  • Create a private enum called CodingKeys that follows CodingKey. ]
    • 

  • Enter all class variables as part of the enumeration
    • 

  • Create custom encoders and decoders for the base class
    • 

  • In the subclass, define a new private enum called CodingKeys . I have marked both private so the compiler knows which variable to know in which function
    • 

  • Create the custom encoders
    • 

  • Encode the variables of the child class and then
    • 

  • Call the encoder / decoder of the parent class 
    • 


			

			

				
				
				
				
			

				

				
				
				
				
				

								
					
				
							
					
				
			
			

			

				
				
				
				
			

				
				
			

				
					

			
					


											
								Intent Based Networking is a journey: Tip #1							
					
															
Intent Based Networking is a journey: Tip #1

					
					
 by  | 12-Mar-2018

				
				
				
				
				
				
				
				
				
			

				
				
				
				
				
			

				
				
				
				
				
			

				
				
				
				
				
			


In a previous blog post I explained that Intent Based Networking not only intoduces new technology but that it also requires change in the way we operate network infrastructures. And that it is in fact a journey, but how do you get started on that journey? With your existing network infrastructure? It’s impossible to throw away every piece of equiment and design and start greenfield.


 (more…)

				
					

			
					


											
								Intent Based Networking is a journey: Tip #1							
					
															
Intent Based Networking is a journey

					
					
 by  | 04-Feb-2018

				
				
				
				
				
				
				
				
				
			

				
				
				
				
				
			

				
				
				
				
				
			

				
				
				
				
				
			
Although I primarily prepared this blog in advance, last week I presented my session at Cisco Live Barcelona in which I presented three tips to start your journey on Intent Based Networking. In this post I would like to provide a bit more thought about why software defined access is needed and what it is gonna entail for every organisation.  (more…)