When I connect to SSH I use port 22 as destination, but when the reply comes back, does it come in on port 22 as well? Or is the client source port randomly assigned as in other TCP communication?
If set up a firewall allowing outbound traffic to port 22 - Do I also need to allow incoming traffic on port 22?
The client SSH port is randomly assigned, as in most client/server systems over TCP/IP.
Were the client port fixed, you would not be able to open multiple SSH connections from the same client IP address, as the connections would be indistinguishable on an IP protocol level. The client port number is the only piece that makes the connection unique (client IP, server IP and server port being the same).
You do not need to allow the incoming traffic though. There is only one outgoing connection in SSH (the responses from the server come over an existing connection).
Related
Through tcpdump in dhcp-server, it shows the server can receive the DHCPDISCOVER package and send the DHCPOFFER package, but can not receive the DHCPREQUEST package from the dhcp-client, so the client can not get IP address and always in send DHCPDISCOVER package.
But the dhcp-server which runs in VMWARE's instance can send DHCPACK to client and the same client will get the IP success. The dhcp-server using the same configure as in Openstack's instance.
And, if I configure the static IP address in the client instance, it will ping the dhcp-server's IP successful.
One more thing, the server and client are in the same vlan.
Is there any limit rule in Openstack's instance? How can I resolve this problem, THX.
The essential reason is that the traffic of port is limited by the security groups in openstack.
By default, all security groups contain a series of basic (sanity) and anti-spoofing rules that perform the following actions:
Deny egress DHCP and DHCPv6 responses to prevent instances from acting as DHCP(v6) servers.
Resolution:
disable security groups (no recommend)
set dhcp-relay to the dhcp server in router (recommend)
security groups limited the traffic by hypervisor's iptables which will drop the packets which's src port is 67 and dst port is 68.
DHCPOFFER packets will send to router by src and dst port 67, and it will works to all vlans.
For DHCP relay and DHCP proxy, packets sent to the DHCP server from the router have both the source and destination UDP ports set to 67. The DHCP server responds using the same ports.
Maybe there are some methods but I can't find out until now ?
If a webserver is handling traffic on port 80, each client must establish a connection between itself and the server on that port. Assuming a client maintains the connection, how is the server able to service other clients in parallel?
Does the server immediately kill the connection with a client after a request? Or do webservers dynamically generate new ports for clients to use such that port 80 is free for new connections?
A port is one end of a communication channel.
The server initials sets up a LISTENing port (80 in the case of an HTTPS server). A client creates a port (the operating system will assign a random, available port number to this) and CONNECTs to the listening port. At that point the communications channel is uniquely described by the IP address of the server, port 80 at the server, and the IP address of the client along with port number of the client. If you look at the output of netstat you'll see lots of sockets/ports in various stages of connection:
symcbean#skynet ~ $ netstat -t
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 192.168.1.202:47206 stackoverflow.com:https ESTABLISHED
tcp 0 1 192.168.1.202:50894 aba1c1ff9d2ec5376.:smtp SYN_SENT
tcp 0 0 192.168.1.202:47210 stackoverflow.com:https ESTABLISHED
tcp 0 0 192.168.1.202:60806 ec2-34-213-90-136:https ESTABLISHED
tcp 0 0 192.168.1.202:51124 151.101.1.69:https ESTABLISHED
tcp 0 0 192.168.1.202:34784 i0.wp.com:https ESTABLISHED
tcp 0 0 192.168.1.202:54082 lhr25s14-in-f10.1:https ESTABLISHED
tcp 0 0 192.168.1.202:38412 172-155-250-212.s:https ESTABLISHED
Exactly how the server handles communicating concurrently on multiple channels varies. I've never come across a server which only handles a single connection at a time.
On the (prefork) Apache webserver, the process which opened the listening socket hands off the connection to a pre-existing child process to deal with. Some servers run as a single process but with multiple threads of execution. Some (such as nginx and lighthttpd) run as a single thread and give their attention to the channel sending data first.
How does SSH dynamic forward (-D) function under the hood?
I understand that SSH dynamic forward opens a SOCSK4 proxy on the local host, and that each connection to the SOCK4 proxy is forwarded over the SSH tunnel to the remote destination.
Does SSH intercept the connections to the SOCKS4 proxy? I mean, it cannot be a "normal" SOCKS4 proxy, because then it would directly proxy the connections to the remote hosts.
Furthermore, how does SSH handle responses from the remote hosts, i.e., how does it transfer them back over the SSH tunnel to the recipients on the local host?
When the -D flag is given, the SSH client will start a built-in SOCKS4/5 proxy. (note: "SOCKS", not "SOCK").
-D [bind_address:]port
Specifies a local “dynamic” application-level port forwarding. This works by allocating a socket to listen to port on the local side, optionally bound to the specified bind_address. Whenever a connection is made to this port, the connection is forwarded over the secure channel, and the application protocol is then used to determine where to connect to from the remote machine. Currently the SOCKS4 and SOCKS5 protocols are supported, and ssh will act as a SOCKS server.
When another application wishes to connect to a proxied service, they will establish a connection via this SOCKS server. The SOCKS protocol is a little bit of negotiation that occurs at the beginning of a connection, something like this: (inspired by the wiki page)
ssh -D 1234 user#remote is execute, the SSH client starts a SOCKS proxy server listening on port 1234.
A local application wishes to communicate with a service via the SOCKS proxy, so connects to port 1234.
The SOCKS client asks for a connection to a particular IP address and port - e.g: 66.102.7.99, port 4321.
The SOCKS server, in this case the SSH client, will negotiate to establish this onward connection with it's server (remote, from above). This may fail.
The SOCKS serve will respond to the client with success / failure information.
If successful, all data passed through this socket will now be forwarded appropriately:
From the local application, to the SSH server (remote), and then onto 66.102.7.99.
From 66.102.7.99 to the SSH server (remote), and then onto the local SSH client, and ultimately the local application.
Does SSH intercept the connections to the SOCK4 proxy?
No, the SSH Client is the SOCKS proxy.
I mean, it cannot be a "normal" SOCK4 proxy, because then it would directly proxy the connections to the remote hosts.
I suppose it's not really - the SSH Client and Server act together to achieve the function of a "normal" SOCKS proxy. The high-level result is that the proxy listens on one host, but forwards data from another host, with a magical link in between.
Furthermore, how does SSH handle responses from the remote hosts, i.e., how does it transfer them back over the SSH tunnel to the recipients on the local host?
TCP is a connection-oriented method of communication. That is to say that once a connection is established, data can flow in both directions, and is reliably identified as "related to that connection". With this information it is trivial to associate the data with arbitrary rules such as "forward to the SSH server, who will forward to 66.102.7.99".
I am working on a project consisting of the bidirectionnal (and secure) connexion of a lot of Raspberry PI -N clients- to a known, accessible, fixed-IP adress Server.
The clients (Raspberry PI) are all connected to the Internet via a classic NAT. Let say clients are identified by a number between 1 and N.
[Client] Raspberry PI <-> NAT (Internet Provider) <-> Internet
All client's public IP are dynamic
The Server is located somewhere on the Internet at the IP address A
--- My GOAL : Connect each client to the server with the SSH protocol. ---
The Server needs to send data at will to any client (no broadcast), and each client needs to send data to the server.
There will be "N" SSH tunnels, initiated by the clients , using reverse-port forwarding or/and port forwarding.
That's where i lack knowledge in SSH:
1) How can the server associate each tunnels with a client in
order to be able to use the proper tunnel ? How can a program (for
example in C) identify and "use" each tunnel for sending and receving
server-side?
2) Using [reverse] port forwarding, what are the needs in ports
server side, does each clients needs a remote port on the server?
3) Do i need to create a program that link each outgoing port to a
client ID and same thing for ingoing port?
My problem is when the server needs to send data to a specific client, how to do it ?
Thank you very much.
Right now I have a client-server program that works over LAN. I have managed to ensure that traffic sent to my server gets past the firewall of my company. However, problems occur when the client is communicating from within a LAN - how can I make sure that traffic gets past the firewall/router of the client and to the machine?
Once the client has sent a packet of data the server analyzes this and is meant to send a response; however the server program seems to freeze after the following lines
Dim ip As String = (IPAddress.Parse(CType(ClientToManage.Client.RemoteEndPoint, IPEndPoint).Address.ToString())).ToString SendResponse = New TcpClient(ip, 8000)
Possible issues are:
- The server's firewall is blocking outgoing TCP traffic at port 8000.
- The client's firewall is blocking incoming TCP traffic at port 8000.
Adjusting your client's and/or server's firewall settings to allow incoming, respectively outgoing TCP traffic at port 8000 might fix the issue.