I am searching about 2 months for a port forwarder with encryption and this is making me almost crazy.
I tell my goal and maybe someone can help me:
I want to forward socks5 packets to another server and make it secure (safe from sniffing) because my ISP parses the socks packets and also blocks some packets. now, I want an open source (rather python, javascript[node], mono, perl) or easy to use command line tcp forwarder with encryption and decryption to forward socks packets to another server.
Thanks in advance!
The program spiped can do what you are asking:
spiped (pronounced "ess-pipe-dee") is a utility for creating symmetrically
encrypted and authenticated pipes between socket addresses, so that one may
connect to one address (e.g., a UNIX socket on localhost) and transparently
have a connection established to another address (e.g., a UNIX socket on a
different system). This is similar to 'ssh -L' functionality, but does not
use SSH and requires a pre-shared symmetric key.
https://code.google.com/p/spiped/source/browse/trunk/README
https://github.com/morgante/spiped-docker
Related
Is there a way one could test whether the communication between two hosts is happening over the IPSec protocol?
I have two different hosts running the OpenSource Peer2PeerVPN solution. And I have one host listening for messages via the net-cat tool.
nc -v -l -p 9999
And the other host connected to this via the VPN tunnel
nc -v 192.168.188.2 9999
I want to verify or check whether the communication is actually happening over the IPSec protocol. Also, I would like to see the values of the IPSec Protocol's Authentication and Encapsulation Headers.
I tried tcpdump but I'm guessing it only provides a capture on the layer above the Network level - Transport.
EDIT:
Based on a comment below I downloaded a sample pcap file to view how headers look in a IPSec communication. I see that these traces have ESP headers of the IPSec protocol.
However, when I try the same with the VPN Tool I'm using I don't see any packets with ESP header on the tcpdump. I was listening on the VPN interface (peervpn0) that the tool creates.
To check if this was a problem with the tool, I connected to a remote server to which I usually connect using VPN and sent some data via netcat to my machine from inside the remote-machine (I ssh'ed in). I listened for all packets on the VPN interface created by the Cisco VPN Tool (utun0) with filter esp
tcpdump -vvv -i utun0 esp
Still, I did not see any traces.
What am I missing here?
Should I listen on the default interface (my wifi interface) via which the VPN tunnel is created to see the ESP Headers?
Or have understood something wrong here?
Thank You
Shabir
With some further reading I was able to find out that PeerVPN does not communicate over IPSec but using encryption and sends the data as UDP payload over the underlying interface.
I also saw that many of the VPN tools indeed do this and does encrypt the tunnel interface packets and forwards them over UDP in the underlying interface. Besides some VPN solutions have a separate option to enable IPSec protocol specifically.
Thank You.
Running on a Linux system, getting UDP packets from another computer address to let's say 192.168.0.2 from another address let's say 192.168.166.66, I can see the UDP packets coming in with tcpdump. However, if I use netcat I don't actually receive the packets.
If I create an interface on 192.168.166.XXX network, then netcat is able to receive the packets no problem.
What basic networking concept am I missing? Why do I need to have an interface on the network of the sending IP when I can see with tcpdump that they are being delivered correctly?
tcpdump per default puts the interface into promiscious mode, which lets you see all the packets arriving at your network interface. But, your operating system only processes packets destined for the local system, e.g. either having the local or a broadcast address as destination.
The final solution to this problem was to disable Reverse Path Forwarding (RPF) on the interface. There are security implications here, but after careful review this was the correct path forward in this particular case.
RPF was turned off by modifying /etc/sysctl.conf:
net.ipv4.conf.eth0.rp_filter=0
Some more information on RPF:
Wikipedia - Reverse path forwarding
Linux kernel rp_filter settings
I'm writing a client/server program which needs to create a secure network pipe between two machines, identifying them both using certificates. The SSH protocol seems like a perfect match for this - its built-in security, support for authenticating both sides, and maturity being big plusses. It can also multiplex connections by using one open connection to connect many generic ports.
The idea is to create an always-on connection (these programs have a dedicated line between the client and server), and to open a port whenever I need one. Can the SSH protocol be used this way? How would I go about incorporating libssh into my programs to support that?
You can do that using libssh. You create a ssh session and for each port you can open a channel for port forwarding. See
http://api.libssh.org/stable/libssh_tutor_forwarding.html
You can even try out this kind functionality with OpenSSH's -M/ControlMaster function.
Both libssh and libssh2 support this functionality.
A little nit: SSH doesn't use certificates, it uses private/public keys.
Oddly I didn't find this info by googling. What is the cost of establishing connection using Unix Domain sockets versus TCP sockets?
Right now I have to do connection pooling with TCP sockets because reconnecting is quite expensive. I wonder if I can simplify my client by simply switching to Unix Domain sockets and getting rid of connection pooling.
If you look into the code, you'll see that Unix Domain sockets execute far less code than TCP sockets.
Messages sent through TCP sockets have to go all the way through the networking stack to the loopback interface (which is a virtual network interface device typically called "lo" on Unix-style systems), and then back up to the receiving socket. The networking stack code tacks on TCP and IP headers, makes routing decisions, forwards a packet to itself through "lo", then does more routing and strips the headers back off. Furthermore, because TCP is a networking protocol, the connection establishment part of it has all kinds of added complexity to deal with dropped packets. Most significantly for you, TCP has to send three messages just to establish the connection (SYN, SYN-ACK, and ACK).
Unix Domain sockets simply look at the virtual file system (or the "abstract namespace") to find the destination socket object (in RAM) and queue the message directly. Furthermore, even if you are using the file system to name your destination socket, if that socket has been accessed recently, its file system structures will be cached in RAM, so you won't have to go to to disk. Establishing a connection, for a Unix Domain socket involves creating a new socket object instance in RAM (i.e., the socket that gets returned by accept(), which is something that has to be done for TCP too) and storing a pointer in each of the two connected socket objects (so they each have a pointer to the other socket later when they need to send). That's pretty much it. No extra packets are needed.
By the way, this paper suggests that Unix Domain sockets are actually faster than even Pipes for data transfers:
http://osnet.cs.binghamton.edu/publications/TR-20070820.pdf
Unfortunately, they didn't do specific measurements of connection establishment costs, but as I have said, I've looked at the Linux source code and it's really quite a lot simpler than the TCP connection establishment code.
Connecting to a server using TCP sockets may involve network traffic, as well as the TCP three-way handshake.
Local sockets (formerly known as Unix domain sockets) are all local, but need to access a physical file on disk.
If you only do local communication then local sockets might be faster as there is less overhead from the protocol. If your application needs to connect remotely then you can't use local sockets.
By the way, if you're only communicating locally, and not over a network, a pair named pipes (or anonymous if you're forking) might be even better.
I am trying to find out the type of the tunnel used for a vpn.. I am trying to determing if the tunnel is tcp or udp.. how do I do that? When I observe the tunnel traffic I am not able to observe anything! In the sense that packets are sent as such..
You need to observe the traffic on the physical network connection, not the traffic in the tunnel itself:
Setup a network packet capture program, such as Wireshark, to capture the traffic on the "real" network interface e.g. your cabled Ethernet connection. On Linux it would be something along the lines of eth0.
(Optional) Shutdown as many processes that use the network as possible.
Cause as much traffic through the VPN tunnel as possible - e.g. download a large file.
Watch in your capture program for any change - the tunnel traffic should now stand out due to sheer volume.
Keep in mind that if you are using an IPSec tunnel, the packets will be ESP, which is neither TCP nor UDP.