EnglishFrenchGermanPolishSpanishTurkishRussianItalianDutchDutch

This feature was discontinued in SecurityKISS


SecurityKISS Forwarding configuration (Octopus Tunneling)

This manual shows how to configure forwarding for Octopus Tunneling


Assumptions

In the example shown below two users are both behind a firewall and want to forward their route:

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



Figure 1 Expected connection structure in Octopus Tunneling


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 the route or who approved it.

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



Figure 2 Peer 1 Client Panel logon dialog for PC 1

On the Forward tab the user can 'Request New Forward Route'



Figure 3 Peer 1 requests a new forward route

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



Figure 4 client00000001 requests forwarding to client00000002 on Chicago server

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



Figure 5 Peer 2 Client Panel logon dialog on PC 2



Figure 6 client00000002 Pending Forward Requests

Peer 2 should accept the request only if he/she 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 the Peer 2 panel on PC 2:



Figure 7 client00000002 Active Forward Routes

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



Figure 8 client00000001 Active Forward Routes


Connection to the 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 normal:



Figure 9 Peer 1 server selection



Figure 10 Peer 1 connected to the Chicago server

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



Figure 11 Peer 2 server selection



Figure 12 Peer 2 connected to the Chicago server

After successful connection a Local IP addresses is assigned for Peer 1: 10.11.113.70 and Peer 2 is assigned 10.10.47.162. 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 a ping request from PC 1:

PC1> ping 10.10.47.162
PING 10.10.47.162 (10.10.47.162) 56(84) bytes of data.
64 bytes from 10.10.47.162: icmp_seq=1 ttl=127 time=256 ms
64 bytes from 10.10.47.162: icmp_seq=2 ttl=127 time=238 ms
64 bytes from 10.10.47.162: icmp_seq=3 ttl=127 time=244 ms
64 bytes from 10.10.47.162: icmp_seq=4 ttl=127 time=281 ms

--- 10.10.47.162 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss

It should work the other way round from PC 2 also:

PC2> ping 10.11.113.70
PING 10.11.113.70 (10.11.113.70) 56(84) bytes of data.
64 bytes from 10.11.113.70: icmp_seq=1 ttl=127 time=233 ms
64 bytes from 10.11.113.70: icmp_seq=2 ttl=127 time=233 ms
64 bytes from 10.11.113.70: icmp_seq=3 ttl=127 time=228 ms
64 bytes from 10.11.113.70: icmp_seq=4 ttl=127 time=279 ms

--- 10.11.113.70 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss

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 a NAT/Firewall.

See possible applications: