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).
Related
I played a bit with the official dpdk by setting up the environment and running some example applications. Then I found out about the UDPDK which combined the DPDK with the UDP stack.
I already have set up the environment for UDPDK as per documentation and then ran the sample app 'pktgen' (both in the local VM and on the public server). Now as far as I understand, this project's aim was to send pure UDP packets between connected devices.
I tried to send UDP packets from VM1(using DPRK) to VM2(normal) and tried to receive packets through a normal UDP receiver (java app) and succeeded, Also was able to send from one server(using DPDK) to another server (normal & both servers are connected to same switch as I could arping between them)
Edit :
My next target / main goal is to send/receive UDP packets from/to 1 public server (using DPDK) to another public server (normal & they are not connected, and no control over switch). Then I came to know about Open vSwitch and been told that this can be the way though I saw DPDK-OVS being used between VM's mainly. Is it really possible to send/receive UDP packets from/to remote public server using DPDK-OVS and if so then how?
Thanks in advance for any help.
For the question can one send UDP packets between 2 servers which are remotely connected (not connected directly or through the switch); the answer is yes, one can do the same without any external or 3rd party switching applciation
Reason:
packets traverse through the local network using Ethernet and VLAN
packets traverse through the remote network using MPLS, IP address or tunnel protocols.
So as long a valid packet with ethernet, vlan, IP, UDP is constructed sending it locally or remotely is possible.
How to do it:
Ensure the port used supports VF
create a VF instance and bind to DPDK
use DPDK API such as pktmbuf_alloc, mtod, eth, IP, udp to create the desired packet.
send a packet on VF interface using tx_buffer or tx_burst.
As long as the right MAC address, VLAN and|or MPLS is right external routing is taken care.
If packets are travelled through the tunnelling via NAT, ip-in-ip or GRE|Geneve, then we have 2 options
Prepare the NAT, tunnelling in DPDK and send over a physical interface
send the custom packet from the DPDK application using TAP PMD into the kernel, using network IP route tables the packets will be forwarded with appropriate tunnelling.
The above second approach takes care of neighbour discovery and tunnelling overhead.
hence the use of DPDK-OVS or OVS or any virtual switch does not solve the underlying issue.
DPDK-OVS provides DPDK vhostuser/vhostuserclient type port as virtual (virtio) device to VM. to VM, the virtio device in VM is just like any other normal network device, the UDP applications runs on VM does not care what underlying network devices the VM runs, UDP receives/sends packet through Linux network stack. you could run another userspace stack on VM and UDP applications runs on top of the userspace stack to bypass VM Linux stack.
I am debugging some code which is using UDP communications.
My CLIENT is behind a NAT and a Firewall.
My Server is an AWS machine on which I opened said UDP ports.
However, part of this protocol involves the server answering my client. Which I expected not to work (NAT & Firewall). To my surprise, my client is recieving packets from the server!
How is this possible? I mean, TCP (over UDP) has a concept of a connection, so I guess that the NATs and routers can associate an incomming UDP packet as a reply to an egress connection. But how (and why) does this work for a pure UDP protocol? Would my NAT/Firewall let in random UDP into my client machine?
How is this possible?
That's how NAT works. You wrote that the server is answering you client. That means that the client initiated the conversation. It doesn't matter that you're using UDP and not TCP. The NAT device still creates an appropriate mapping to let answers trough. Otherwise all UDP would have been broken behind NAT.
I mean, TCP (over UDP) has a concept of a connection, so I guess that
the NATs and routers can associate an incomming UDP packet as a reply
to an egress connection. But how (and why) does this work for a pure
UDP protocol?
The fact that UDP isn't connection-oriented is irrelevant. Sure, TCP has the concept of sessions, but both have port numbers and that's really all the NAT needs.
Would my NAT/Firewall let in random UDP into my client machine?
It's not "some random UDP". It's a UDP segment from the same IP and port number that the client sent something to.
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.
I am looking at traffic generated by my computer when socks server is defined.
I read over the internet and see that its possible to route udp also trough the proxy server.
when i try using different apps that uses UDP and allows socks settings, it uses it only for tcp traffic. why?
I have defined SOCKS5, as i understand that v4 doesnt support udp (why?)
i tried an example, Vuze client - its expert mode allows to prefer udp traffic, setup socks server and even at this point, any udp goes directly to peers.
My wish is to monitor the traffic and see how its transmitted, is it over UDP connection with socks server, or does it actually connects to the socks server in TCP and sends the data, which is then sent via udp to the destination?
When a client wants to relay UDP traffic over the SOCKS5 proxy, the client makes a UDP associate request over the TCP. SOCKS5 server then returns an available UDP port to the client to send UDP packages to.
Client then starts sending the UDP packages that needs to be relayed to the new UDP port that is available on SOCKS5 server. SOCKS5 server redirects these UDP packages to the remote server and redirects the UDP packages coming from the remote server back to the client.
When client wants to terminate the connection, it sends a FIN package over the TCP. The SOCKS5 server then terminates the UDP connection created for the client and then terminates the TCP connection.
Double SSH Tunnel Manager support SOCKS5 With UDP
3proxy Server support UDP
You have two application that need to exchange information among them in a local area network. The first application uses TCP for communication while the second uses UDP. Can we link both applications directly? If your answer is no, explain how we can link them?
(from a homework assignment)
I think the answer is no, we need to use some translator or middleware between them. But what?
As you figured out, you can't simply combine 2 types of connections into one.
TCP is a state-full connection, which requires two computers to establish the connection,
opposing to UDP which is stateless/connectionless connection that requires just one computer, send and forget style.
If you want them to communicate with each other, you must have a middle-ware.
The TCP application should have a TCP Client and TCP Server
The Middle-ware should have a TCP Server that will listen to the TCP application's client and establish connection and a TCP Client that will establish connection with the TCP application's server.
Now the middle-ware can fully communicate with the TCP Application.
In order to do so with the UDP Application, you should listen to UDP at a certain port in order to listen to incoming data from the UDP Application, and send to it over UDP to the UDP Applicaiton (the UDP Application need to listen on that port)