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
Related
Here are my understandings about these and I see few gaps there; especially when and where to use
HTTP(s) proxy:
Can be used as TLS termination proxy
Can be used to modify HTTP headers
Can be used as a load balancer or a public IP provider in front of DMZ to shield backend servers
TCP Proxy
Can be used as reverse proxy for TCP connections and can support not only HTTP but also other application layer protocols such as FTP
My question(s)
If I only accept HTTP web traffic what are the use cases where we should use TCP proxy instead of HTTP Proxy
Is this understanding connect? TCP clients can connect to a single socket on TCP proxy and TCP Proxy can open up multiple connections to the backend servers something similar load balancers
SOCKS5 Proxy
From Wikipedia
Socket Secure (SOCKS) is an Internet protocol that exchanges network packets between a client and server through a proxy server. SOCKS5 additionally provides authentication so only authorized users may access a server. Practically, a SOCKS server proxies TCP connections to an arbitrary IP address, and provides a means for UDP packets to be forwarded.
SOCKS performs at Layer 5 of the OSI model (the session layer, an intermediate layer between the presentation layer and the transport layer). SOCKS server accepts incoming client connection on TCP port 1080
My questions
What is the use of SOCKS proxy in an web application
Difference between TCP and SOCKS5 proxy
In TCP/IP model is it a transport layer protocol
What are the use cases for proxying UDP connections
If I only accept HTTP web traffic what are the use cases where we should use TCP proxy instead of HTTP Proxy
A TCP proxy terminates the incoming TCP socket, opens outbound socket and moves data in between. It doesn't/can't change the data in between since it doesn't understand any of it. Most often, a TCP proxy is statically configured and can only create connections to a single host:port combination.
An HTTP proxy understands HTTP. It looks at the incoming HTTP request and uses an outbound, potentially changed HTTP request to fulfill the request. The proxy can read the HTTP request's host address and connect to multiple hosts that way. It is aware of the HTTP application level which a TCP proxy isn't. Some HTTP proxies can even fulfill FTP or HTTPS requests for clients just using HTTP.
A "forward" proxy is a proxy connecting from private to public IP space (which was the original idea for a proxy) while a "reverse" proxy connects from public to private IP (e.g. mapping to multiple web servers from a single, public IP). Technically, it's the same, but from the security POV there's a huge difference (in "forward" you trust the clients, in "reverse" you trust the servers).
Is this understanding connect? TCP clients can connect to a single socket on TCP proxy and TCP Proxy can open up multiple connections to the backend servers something similar load balancers
Yes.
Difference between TCP and SOCKS5 proxy
SOCKS5 is a general proxy protocol that can do more than a TCP proxy, including one-to-many connections, listening ports, and UDP.
In TCP/IP model is it a transport layer protocol
To me, SOCKS5 is an application layer protocol to arbitrate a transport protocol connection. Some argue that SOCKS5 is a session layer protocol in between transport and application layer - that holds some truth but the session layer is ill-defined in TCP/IP.
What are the use cases for proxying UDP connections
For instance, SOCKS5 can be used for private-to-public Internet access or for (insecure) public-to-private LAN access.
I am looking for a way to test UDP connection, I tried with some VPN servers that I know they have XXX UDP port open, but I didn't know what to send in the body, when I send random strings I don't get any respond
Is there any reliable server that have some UDP port open all time and respond to my connections
My friend told me that TCP doesn't need port forward.
What exactly he said is if the server is port forwarded the client can request something and the server will respond without port forward.
And I agreed with that even though I'm not sure it is true.
Later he said it is the same with UDP which I do not believe.
MAINLY THE QUESTION IS
If a client requests something on a server with TCP, does it need to be port forwarded to receive the response?
Also is it the same for UDP?
If the request from the client is a SYN for connect call then only a SYN-ACK response will be allowed through NAT. If the NAT supports simultaneous open connection then a SYN response from server will also be allowed through NAT. After the connection is established then client and server can communicate freely without any restriction. Port forwarding is not needed.
For UDP after a packet from client to server is sent then anything from server can be received through exact same public port of the NAT from which the first packet was sent. No port forwarding needed.
Ive build a local multiplayer game (multiplayer over wlan network). Now, I want to add an online multiplayer feature..
Currently, the network communications consist mostly of "signals" (tcp/udp packets sent from game-host peer to the game-client peers). I would like to use this mostly signal based communication for my online multiplayer (because of performance and efficiency ), too . But, since the host peer is now replaced by a server there will be a lot problems with sending signals (NAT, firewall,...).
So is there good solution to implement these signals?
regards
there will be a lot problems with sending signals (NAT, firewall,...)_
What problems exactly?
Normally, the clients establish a TCP connection to the server and the server uses this TCP connection to communicate with the clients.
For UDP-based communication the clients use Internet Gateway Device Protocol to forward ports on the router, so that the server can send UDP datagrams to the clients.
Assuming your server is in public internet, not behind any NAT. All the clients must initiate the connection. Otherwise the server can't know clients credential and can't connect. As the server has no NAT it will accept connection from client. And this connection client must keep alive. So when server needs to send some data there should be no problem.
This will work for both UDP and TCP.
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)