I always check network connectivity using telnet [IP] [port]. However, sometimes the connection timeouts because nothing is listening to that port but the tunnel to that port is open. How do I check the difference, i.e. does telnet timeout because tunnel is not open or because nothing is listening to that port at the other end?
Probably by using tcptraceroute, from the man page
This program attempts to trace the route an IP packet would follow to
some internet host by launching probe packets with a small ttl (time to
live) then listening for an ICMP "time exceeded" reply from a gateway.
We start our probes with a ttl of one and increase by one until we get
an ICMP "port unreachable" (or TCP reset)
set the max_ttl value to be appropriate for your firewall
Related
I am sending packets to a Windows network card (eth1) using the Linux sendto() function and a RAW socket (socket(AF_INET, SOCK_RAW, IPPROTO_RAW);). However, although the packets are addressed to the IP address of the network card, the host OS appears to "ignore" the packets.
For example, the network card has IP 192.168.1.2, and my userspace application sends a network packet containing a ping addressed to 192.168.1.2. I can observe in Wireshark the ping arrive on the network device at 192.168.1.2, however no reply is generated. The TTL on the ping is non-zero, so I'm lost as to why the host OS would appear to "ignore" packets destined for it.
Equivalently, if I create a UDP socket and bind it listening to 192.168.1.2 on port 5050, and then send a userspace UDP packet addressed to 192.168.1.2 on port 5050, the packet is never delivered to the port.
What would cause a packet to be ignored by the network card that receives it?
Is there any socket flag needed if I'm sending packets in from userspace (over a custom IP tunnel) to force processing of the packets, as if they came from a router?
The issue turned out to be the native windows firewall, disabling the firewall fixed this issue.
In addition, if republishing network packets on a network device, if a single device (mac addr) is publishing multiple ip packets from various source ips, windows may filter out packets with the assumption that mac<->ip is a unique 1:1 mapping.
THIS IS ALL UDP
Let say I have an internal port 25000 that isn't forwarded.
I send a UDP Message through that port to a server.
I now listen to that 25000 port locally for a reply from that server.
The server received my message.
The server thinks the port the message came from is 27833.
How much time does the server have to send a message back to me through port 27833?
If I locally keep listening to port 25000 will the 27833 port stay open indefinitely until I stop listening?
I'm not an expert but I think the timeout of the forwarding of the port on the NAT will not be influenced because you listen to new datagram on a computer behind your NAT (As only the OS will know you want to read those packets, not the NAT).
For the time the port will be forwarded by the NAT, I've find this response on stackoverflow: For how long a router keeps records in the NAT and can they be reused forwarding requests from other hosts? (Shortcut from the response, in practice less than 120 sec)
I have a load balancer group with few target servers and they are SSL enabled.
Now I want to do the TCP monitoring on the target servers port (443)
Does TCP monitor work with the backends which are on https ?
TCP Monitor, according to me, does a socket connect on the given Host and Port. What this means is, if there is an open port on the target server, then server is considered alive and kicking.
Since this is only a socket connect; protocol HTTP,HTTPS does not matter as long as there is port open and has a listener on the port.
Port 80 accept two different protocols: HTTP and Stratum. The latter is a line-based protocol always start with '{'. If the client connect to port 80 and sends something like 'GET / HTTP/1.0...', forward the connection to port 8000, if it sends '{"id": 1,...', forward it to port 3333. Is it possible to do it with iptables? Thanks!
I don't think you can do that with iptables.
The problem is that, at the time you can detect the first byte of the TCP payload, a connection has been established between source:port to server:80.
Forwarding the packets in mid-connection will result in the packets being rejected, because the TCP stack never sees the SYN/SYN-ACK packets for connection establishment to ports :8000 or :3333.
You'll need something listening on port :80, then based on the very first by received, open a connection to port :8000 or :3333 and replay the contents. That something must also perform reverse-replay of the webserver's/Stratumserver's replay toward the connection initiator.
Some things look strange to me:
What is the distinction between 0.0.0.0, 127.0.0.1, and [::]?
How should each part of the foreign address be read (part1:part2)?
What does a state Time_Wait, Close_Wait mean?
etc.
Could someone give a quick overview of how to interpret these results?
0.0.0.0 usually refers to stuff listening on all interfaces.
127.0.0.1 = localhost (only your local interface)
I'm not sure about [::]
TIME_WAIT means both sides have agreed to close and TCP
must now wait a prescribed time before taking the connection
down.
CLOSE_WAIT means the remote system has finished sending
and your system has yet to say it's finished.
I understand the answer has been accepted but here is some additional information:
If it says 0.0.0.0 on the Local Address column, it means that port is listening on all 'network interfaces' (i.e. your computer, your modem(s) and your network card(s)).
If it says 127.0.0.1 on the Local Address column, it means that port is ONLY listening for connections from your PC itself, not from the Internet or network. No danger there.
If it displays your online IP on the Local Address column, it means that port is ONLY listening for connections from the Internet.
If it displays your local network IP on the Local Address column, it means that port is ONLY listening for connections from the local network.
Foreign Address - The IP address and port number of the remote computer to which the socket is connected. The names that corresponds to the IP address and the port are shown unless the -n parameter is specified. If the port is not yet established, the port number is shown as an asterisk (*). (from wikipedia)
What is the distinction between 0.0.0.0, 127.0.0.1, and [::]?
0.0.0.0 indicates something that is listening on all interfaces on the machine.
127.0.0.1 indicates your own machine.
[::] is the IPv6 version of 0.0.0.0
My machine also shows *:\* for UDP which shows that UDP connections don't really have a foreign address - they receive packets from any where. That is the nature of UDP.
How should each part of the foreign address be read (part1:part2)?
part1 is the hostname or IP addresspart2 is the port
127.0.0.1 is your loopback address also known as 'localhost' if set in your HOSTS file. See here for more info: http://en.wikipedia.org/wiki/Localhost
0.0.0.0 means that an app has bound to all ip addresses using a specific port. MS info here: http://support.microsoft.com/default.aspx?scid=kb;en-us;175952
'::' is ipv6 shorthand for ipv4 0.0.0.0.
Send-Q is the amount of data sent by the application, but not yet acknowledged by the other side of the socket.
Recv-Q is the amount of data received from the NIC, but not yet consumed by the application.
Both of these queues reside in kernel memory.
There are guides to help you tweak these kernel buffers, if you are so inclined. Although, you may find the default params do quite well.
This link has helped me a lot to interpret netstat -a
A copy from there -
TCP Connection States
Following is a brief explanation of this handshake. In this context the "client" is the peer requesting a connection and the "server" is the peer accepting a connection. Note that this notation does not reflect Client/Server relationships as an architectural principal.
Connection Establishment
The client sends a SYN message which contains the server's port and the client's Initial Sequence Number (ISN) to the server (active open).
The server sends back its own SYN and ACK (which consists of the client's ISN + 1).
The Client sends an ACK (which consists of the server's ISN + 1).
Connection Tear-down (modified three way handshake).
The client sends a FIN (active close). This is a now a half-closed connection. The client no longer sends data, but is still able to receive data from the server. Upon receiving this FIN, the server enters a passive close state.
The server sends an ACK (which is the clients FIN sequence + 1)
The server sends its own FIN.
The client sends an ACK (which is server's FIN sequence + 1). Upon receiving this ACK, the server closes the connection.
A half-closed connection can be used to terminate sending data while sill receiving data. Socket applications can call shutdown with the second argument set to 1 to enter this state.
State explanations as shown in Netstat:
State Explanation
SYN_SEND Indicates active open.
SYN_RECEIVED Server just received SYN from the client.
ESTABLISHED Client received server's SYN and session is established.
LISTEN Server is ready to accept connection.
NOTE: See documentation for listen() socket call. TCP sockets in listening state are not shown - this is a limitation of NETSTAT. For additional information, please see the following article in the Microsoft Knowledge Base:
134404 NETSTAT.EXE Does Not Show TCP Listen Sockets
FIN_WAIT_1 Indicates active close.
TIMED_WAIT Client enters this state after active close.
CLOSE_WAIT Indicates passive close. Server just received first FIN from a client.
FIN_WAIT_2 Client just received acknowledgment of its first FIN from the server.
LAST_ACK Server is in this state when it sends its own FIN.
CLOSED Server received ACK from client and connection is closed.
For those seeing [::] in their netstat output, I'm betting your machine is running IPv6; that would be equivalent to 0.0.0.0, i.e. listen on any IPv6 address.