Gaming on the go: How I game remotely and keep my firewall “Perfect Dark”

There are times when I must travel or even where I stay at my partner’s/friend’s place, but to be honest, I don’t sleep that much, so I like playing my videogames during night hours. However, I don’t always take my gaming computer with me (TBH looks fancy as it is, ignore my poor cable management abilities). 

I remember the first security conference I participated in as a speaker. It was back in 2008. A friend of mine asked me to help him fill up a space with a topic I was doing at that time, “Port Knocking”.

For those who are not that familiar with the term, Port Knocking is a stealth method to open ports that, by default, the firewall has closed. It works by having a daemon listening for connection attempts to certain closed firewall ports. When the correct sequence is received, the firewall opens the port for the specific IP address and a specific port to allow the connection. Obviously, Port Knocking must be used as a part of a security strategy and not as the only protection.

As a security enthusiast and a geek, I try to combine my passions. So, for a very long time I continued using Port Knocking (PK) for accessing my public servers. Some of those I have as honeypots for gathering Threat Intelligence; one was used to have a VPN service that allowed me to access those assets.

It was good… but a real pain in the rear; why? Well, first, the VPN management. I’m not that big, but from time to time, adding extra profiles, defining access, changing time to time the PK sequence… I had to create a python script that allowed me to dial the correct PK sequence before trying to open the VPN port and get a VPN connection to my internal endpoints. As you can read and see so far… many steps are involved to gather access. More importantly, it wasn’t secure enough because, in my current country, you’re always behind a NAT (even sometimes a NAT behind a NAT), so when my PK sequence opens the port… it’s open for many others.


Then I found OpenZiti.  And I immediately fell in love with it, no more custom scripts, no more providing full access or inbound ports. And the best part, I do have the ability to design as I need it.

I am going to skip the installation and initial setup. So, it is assumed that you have the basic Ziti network setup and have ZAC in place to add access to systems, or at least you have the ziti CLI in place. If not, you can follow the QuickStart.


   A fully deployed Ziti Network, with the CLI configured or ZAC in place to add access and create configurations. You can follow the QuickStart, if you don’t have it yet.

     Ziti Client installed on your Windows Gaming Machine.

     Ziti Client installed on your working computer (like in my case).

Let’s see how simple and secure this is:

1)  Create the identity for the Hosting workstation. You can assign as many attributes as you want. Openziti works with an "attribute-enabled role-based access control (ARBAC) model. So, if you have used hashtags, you’re probably familiarized with it. 


As you can see in the image above, we’re defining two attributes for this identity “GameDevice” and “WorkstationDevice”, those are definitions of what this device does for me. We will refer one of these later.


2)  Create or add the additional tags to the devices that eventually will have access to the game device.



Again, the attributes defined on this eventually will allow me to using service-policies according to my needs. Particularly, we’re focusing on the one called “gameClient”. So that’s my way to define this workstation works as my game client device.


3)   With the identities in place, now we need to create the service that will define the “how” we’re going to connect to our resource. That means creating a service with 2 configuration definitions:

a.   A ziti-tunneler-client configuration, to intercept the traffic in the client and redirect it to the proper gaming workstation.

There’re a few things to notice in the previous screenshot:

   We’re assigning to our service the name “DragonRDP”

   We’re assigning the attribute “gameRDP” to this service.

   Finally, this configuration will intercept all calls made to the host “dragon.natashell.ziti” via the TCP port “3389”. As you can see, this highlight one of the features I most love, private DNS and this may be different for each client who needs it.


b.  A ziti-tunneler-server configuration, as we have installed a ziti client on our gaming device. Here we define how that client will connect to the ip/port we want to access.

Again, let’s dissect what we have just done. We just created a server configuration saying the tunneler installed in the workstation/server will redirect the traffic internally to the port 3389. 

4)  Now we need to authorize the services. The first identity we want to authorize is the 'host'. We do this by defining a 'Bind' policy. A 'bind' policy allows us to define what identities can provide access to other identities on the OpenZiti overlay network.

Looking at this closer, this policy is authorizing the “Dragon” identity to provide any services which have the “gameRDP” attribute defined. OpenZiti is using "attribute-based access control (ABAC). If the value assigned here begins with a `#` it will match attributes for the given type. If it starts with with a `@`, it matches identities directly.


5)  Finally, we need to authorize clients. A 'dial' policy allows us to define the identities which are allowed to access the matching services.

If we take a closer look into this Policy, what we’re doing is authorizing all devices/identities that have the attribute named  “gameClient” to communicate with the services with the attribute “gameRDP”.

6)   You can always review your current settings and see if everything is in place. In order to do that, you can go to the identity you’ll use to connect to the service and just click on the service you want to test (for our purposes the “gameRDP” service).


You can also use openZiti cli to review the policy created:

And we’re all set, we have successfully configured the connection to our game station and now we can RDP into it and enjoy some videogame entertainment.

 And there you go, in less than 5 minutes openZiti allows us to connect to any service, any computer, any “edge” in a easy and incredible secure way.


While this blog entry was to show you how easily you can solve a “geek” challenge, OpenZiti allows you to access anything anywhere in a secure way.

Take a look at some of my personal examples:

1)   I can manage my own internal infrastructure deployed on my personal server using OpenStack, wherever I may be.


2)  Access to my Jupyter instance to start looking for any threats or start any investigation/remediation process.

3)  Access to my Sharing Information Platform to keep updated with latest threats.

And all that, was done using a single OpenZiti service, which allow my own devices to have access to those assets.

And assign this service to my own workstations I want to access from.

Perfect Darkness!


Popular posts from this blog

Enhance your Network Security with Zero Trust and OTP

Embrace Secure Sharing with Zrok

ZDBC: The Future of Private Database Access