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.
Related
I am running server and client in same system. TCP protocol is used for communication between them. In a scenario where client wants to send packet to server, will it go through network infra (i.e. router, internet etc) and come to server or will it manage transfer within system and ignore network.
If you are on the server, any communication you initiate to IP addresses also on the same server will never leave the server.
You can test by installing tcpdump then running from the console/keyboard/mouse:
tcpdump -n -i enp0s5 not arp
Do not generate network traffic. Try to ssh to your account on IP 127.0.0.1 (e.g. risner#127.0.0.1).
Also try to initiate ssh to another host on the network.
Nothing should show on tcpdump, so that indicates it is not leaving the machine.
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
If i understand correctly, SSH tunnelling allows for the binding of a local port to a remote port through a SSH server. If I'm right, could something similar be done with IPsec?
Yes, an IPSec VPN sends traffic through IPSec and split tunnelling is where you only send some of your data through the vpn.
I've not played with split tunnelling much and I've only seen it configured to split traffic by destination IP, but I'm sure there will be ways to do it by tcp/udp port. Can't really point you to more information without knowing what OS you want to do this on.
Hope this helps.
If i established openvpn connection through udp(proto udp), can i use tcp in it(tcp convert to udp somehow), or only udp?
In short: Yes, you can send TCP through an VPN-Tunnel which is transported via UDP.
In fact you can tunnel any protocol support by OpenVPN no matter what transport you choose.
You can use any protocol you like, even raw IP. OpenVPN simulates a fully-fledged network device (to some extend – whether it's based on the Ethernet or the IP layer depends on configuration) which behaves like any other network adapter. So you can of course use TCP and UDP in it.
The packages sent via the OpenVPN devices are encrypted and passed through the UDP “connection” used by OpenVPN to the remote side, where they're decrypted and passed on to routing to forward them to their final destination (which might be the remote itself).
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.