SecurityKISS Forwarding configuration (Octopus Tunneling)

This manual shows how to configure forwarding for Octopus Tunneling

Assumptions

In the example we are going to describe we have two users behind firewalls:

• Peer 1 on PC 1 with SecurityKISS Tunnel installed identified by client ID: client00000001
• Peer 2 on PC 2 with SecurityKISS Tunnel installed identified by client ID: client00000002

We are going to configure forwarding in order to let the peers (and devices) to see each other as if they are in the same local network:

Client Panel configuration

In this example Peer 1 is the originator and requests forwarding to Peer 2 however the roles can be reversed. Once the forward route is accepted, forwarding is bidirectional and it does not matter who requested and who approved it.

In order to request a forward route Peer 1 logs on to Client Panel:

On the Forward tab 'Request New Forward Route'

Peer 1 needs to know two things in order to do it: client ID of the other peer and server where forwarding will be active. If peers want to use many servers, forwarding for every server must be configured individually.

After clicking the 'Request' button the corresponding entry should appear in the Peer 2 panel on PC 2:

Peer 2 should accept the request only if he is able to confirm that client00000001 belongs to Peer 1. In practice client IDs can be exchanged by email, phone or instant messenger.

Accepted entry immediately appears in Active Forward Routes:

in Peer 2 panel on PC 2:

and the complementary route in Peer 1 panel on PC 1:

Connection to SecurityKISS server

Both peers should connect to the selected SecurityKISS server.

In this example Peer 1 selects the Chicago server on TCP port 443 and connects as normally:

Peer 2 does the same on PC 2. He can use different port/protocol option as long as it is on the same server. We are selecting UDP port 123 here:

After successfull connection Local IP addresses have been assigned: 10.11.113.70 to Peer 1 and 10.10.47.162 to Peer 2. Now they can be used to address the other peer in direct one-to-one connections.

Communication between peers

Peer 1 can check if Peer 2 is accessible by sending ping request from PC 1:

It should work the other way round from PC 2:

Now you can set up any service on one PC (FTP, Remote Desktop, Web Server, Games etc.) and it will be accessible from the other PC even if both are behind NAT/Firewall.

See possible applications:

• Remote Desktop