We have two Debian servers connected to a router which is part of a public network. One of them is email server based on postfix and dovecote and rouncube. Second one is DHCP, DNS, Apache,squid3 based system hosting website and distributing internet to 200 computer LAN. we recently received email from ISP with following note.
"we have again observed multiple outgoing tcp syn based suspicious traffic from your institute towards various chinese destination ip's since morning hours. kindly inform the concerned team regarding the same observation so that adequate measures are taken to curb such traffic "
Considering types of users of my LAN, it is impossible to think that my LAN users can deliberately do it.
Can some computer from outside our network mimic tcp syn based suspicious traffic from MY institute?
Can email server with some silly configuration mistake be responsible?
If your ISP is informing you that your computers are originating the traffic then you can rely on it to be true. What you should do is ask for more detail about the offending SYN segments so you can set up a tcpdump session to capture them on your side and find out which of your LAN users is misbehaving.
Related
I have no filters applied, but am not seeing any traffic other than what appear to be conversations at the Link Layer between my computer's NIC and the router. It is connected via Ethernet, and I believe at one time I could see HTTP, TCP, UDP, etc.
Any suggestions would be appreciated. I've tried visiting Websites and received nothing clearly from those sites.
I would like to ask a general newbie question. I understand that for a computer in location A to connect to a server in location B, packets of data have to be sent to multiple data centers through multiple gateways and through multiple verification channels to ensure the connection request finds the right destination.
However after the connection is established, when the computer and the server send/receive data, do these data still need to go through [multiple data centers through multiple gateways and through multiple verification channels]?
Every TCP / UDP packet can have a different network path between source to destination. However the connection establishment of a TCP connection being stateful is all about what packet size, compression method etc.
At network layer- Connection is stateless. Please read about OSI model in detail also you can refer to this https://www.ccnahub.com/wp-content/uploads/2013/09/watermarked-pc1-comm.jpg It has good explanation of how OSI works.
A TCP packet being sent from computer A to computer B will be addressed to a particular IP address. If that TCP address is not on the local LAN, it will go first through the local LAN to whatever is designated as the local gateway. That gateway then sends it on over the connection to an external network. At that point, it will be delivered to some router in your ISP. That router will look at the destination IP address and consult a routing table to find where it should next send the packet. That will typically be another router elsewhere in the network. This continues and (assuming good routing tables in each router) the packet will get closer to its end desination on each hop. Eventually, the packet will get to a router that has a routing table that knows about either the actual IP address or the home gateway for that IP address and the packet will be sent to that gateway. That home gateway can then deliver the packet to that actual IP address. In some cases, there may be a private network at either end where private IP addresses/port combinations are converted to public IP addresses and vice versa.
If computer A sends multiple packets to computer B, they do not have to all go the exact same path, though typically they will (assuming no problems or congestion in the network between the two endpoints).
In this scenario where A and B are on different private networks, there is no direct connection between computer A and computer B so each packet has to follow the path from one router to the next until it arrive at the final gateway and then destination address.
However after the connection is established, when the computer and the server send/receive data, do these data still need to go through [multiple data centers through multiple gateways and through multiple verification channels]?
If the routers are doing their job appropriately, the very first packet takes the most efficient path from A to B that the network knows. There is no "better" way to send subsequent packets. Subsequent packets will follow the same process (to a router, router looks up in routing table where to send for next hop and so on). If the two endpoints are a long ways apart (in terms of network topology), then the packet may go through many routers. Routers are highly optimized pieces of equipment capable of passing off millions of packets a second as this is how data moves on any TCP/IP network like the internet.
There is no difference in how the first packet that initiates the TCP connection flows versus subsequent packets. At the network level, they are just packets traveling from a source IP address to a destination IP address. Once the connection is established, a reliability layer will be started to track packets that might get lost, initiate retransmissions, etc... but this doesn't have anything to do with how a given packet gets from A to B.
I'm trying to develop an applicaton for p2p communication between two android devices. In order to punch a hole through my NAT(s), I'd need to know my external ip address and port.
To that end, I've developed a java server on GAE to report my "remote" ip address and port. The problem is that on GAE I can get my ip address, but not my port. Without it, I'm unable to successfully punch the hole.
So, my question is what's the best, free method to find out my external IP address and port?
That's a question that has no answer with TCP.
Here's the problem: your "port" is not a fixed value. You don't have "an" external port. You typically get one dynamically assigned for each outbound connection.
As answers you should see from the test sites posted in another answer clearly indicate, it's a moving target (though it may stay stationary for a short time due to the browser using HTTP/1.1 keepalives and actually reusing the same connection, not just the same port)... but if you hit the site repeatedly, you'll see it either drift around randomly, or increment. Trying it from two different web browsers on the same machine, you'd never see the same port number -- the port corresponds to the specific source connection, not the machine sourcing the connection.
Sometimes, you may find that it's the same port number as the port your machine's stack opened for the outbound connection, but even when it is, it doesn't matter, because no traffic should be able to return to your machine on that port unless it is from the IP address and port of the machine to which you made the outbound connection. Any decent network address translating device would never accept traffic from another source IP address and/or port, other than the one you addressed in the outbound connection.
There is no standard, simple, predictable, reliable, or consistent way to punch a hole in TCP NAT and then exploit that hole for a peer-to-per connection. To the extent that such things are possible in a given NAT implementation, that is an implementation that is shoddy, broken, defective, and insecure.
See also: https://www.rfc-editor.org/rfc/rfc5128
Sounds like your app could use a STUN server to get its external address.
Im not too sure why this wont work. My application works fine if the client and server are ran on the same PC hence the 127.0.0.1 but it wont connect to my other laptop using IP 82.41.108.125 which is the IP of that device.
Any reason why this is happening?
Your firewall could quite possibly be blocking the port assuming all of your coding is working fine - try opening up the port number you're running the application on (in the client/server comptuers' firewall options).
Some additional information that should shed some light on things
Networked devices use ARP (Address Resolution Protocol) and RARP (Reverse Address Resolution Protocol) to map IPs to link layer (MAC) addresses and back. Your network interface card (the thing that plugs into your ethernet cable) will have a unique MAC address on both computers. Each PC has an IP configured for it which is used by higher level protocols (those in the Network Layer).
Computer A will know computer B's IP address (and it will be different from computer A's) if your program works correctly. When computer A goes to send to comptuer B, assuming they're directly connected and not going through a router or something in between, computer A's link layer will need to translate that IP for comptuer B into a MAC address it can use. It does this by sending out a broadcast to all network PCs on the same sub network asking "Hey, is this your IP!?" essentially. The one that has an IP matching the broadcasted one yes, "Yes, it's mine - and here's my MAC address so you can talk directly to me."
So, if two computers have the same IP this all goes to hell :) don't do it - give them unique IPs and make sure that comptuer A transmits to the same UDP port and IP that computer B is listening on as well. communications work in {IP, Port} pairs - its like a telephone number and area code.
Also...
As said by EJP - UDP is a connectionless protocol - computer A just sends to computer B and hopes that computer B is listening correctly. If computer B wasn't listening or was but wasn't in the right state to process the data, the data will simply be dropped and lost. Computer A will not know that this happened. If you want reliable communications where it will keep trying and you will have assurance that compuer B received computer A's data then use TCP instead - it does a 3 way handshake to establish a connection and uses acknowledgements to ensure data is retransmitted when it doesn't reach the other end.
It could be that you're listening on localhost (127.0.0.1) and don't accept other traffic. Use a wildcard address.
Check on the server with netstat -npu.
If that's not the case then it's probably firewall issue, verify with tcpdump or wireshark.
Check firewall on your laptop... Most of the time that acts as spoilsport.
I'm currently working on the UDP networking of a game.
Let's say there are two players on the same NAT/LAN. They consequently share the same external IP. They both join the same game server which is at another location and has a different external IP.
How can the game server send UDP packets to a specific player over the LAN?
Everything is fine when every player is on a different LAN, but when two or more are on the same LAN I know don't how to reach them.
BTW I'm using C# but I guess it doesn't really matters here.
By your description I assume their access to the server is through a NATting device. In this case you don't have anything to do, the two clients will be seen coming from the same IP address but different source port, hence easily distinguishable.