I'm using a sniffer (such as Wireshark) to monitor network traffic.
I have no prior knowledge of the network topology. My purpose is to identify IPs as load balancers or NAT entry points.
How can I identify that a particular packet originated from a load balancer or has come through a firewall and has had port based network address translation (NAT) performed on it?
What identifying characteristics are there for either use case?
If there is no layer-3 (router) device between your point-of-capture and the balancer/firewall devices are layer-3, you could use the source-MAC to detect where the packets came from.
Actually, a lot depends on how the network appears from where you capture the packets.
Are the load-balancers on a different path/direction from the firewall? Like, is the firewall on the Internet side and the balancers towards the servers (or are they balancing the Internet link)?
Where are the layer-3 devices? Any between the capture point and these other devices? Are the balancer and/or firewall working as layer-3 devices?
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 know that when two machine communicate they may use the TCP/IP protocol.. But after the IP packet is routed to my router and it is converted to physical signal , how does my computer again decapsulate it and send it to proper application....I know that transport layer header is used for identifying port numbers to send it to proper process,but which device will do all these inside a host..am new to network and apologize if something was wrong or silly here
A packet comprises of information in the form of [header[body]] which will be looked up and processed across all the layers in the TCP/IP stack.
The information related to the all layers are encapsulated into a single packet.
Packet being a general term here, can be of many types based on the protocol with which two nodes are communicating (TCP Packet, UDP Packet, IP Packet etc). The information from a TCP/IP packet for example, are processed by different devices or services working at specific layers.
Switches or Bridges operate at the Ethernet layer. These devices switch packets inside LAN by looking up the MAC address information.
Routers operate at the Internet Layer and utilizes the IP protocol (i.e., IP address) to route traffic between networks.
Stateful firewalls, Proxies, Load Balancers etc. are at the transport layer. They work based on the TCP or UDP information to allow/deny/direct traffic.
Application layer facilities effective communication between application programs in a network. The application layer is not the application itself that is doing the communication. It has protocols such as DNS, FTP, SMTP, SNMP to help and serve the purpose.
References:
https://docstore.mik.ua/orelly/networking/firewall/ch06_03.htm
https://technet.microsoft.com/en-in/library/cc786128(v=ws.10).aspx
I'm exploring alternate multiplicities between IP subnets and VLANs, outside the recommended 1-to-1 implementation. My understanding is as follows:
Multiple subnets to a single VLAN (connected via a switch):
Hosts across both subnets would receive layer 2 broadcasts (such as ARP), but would ignore traffic lacking an IP that targets them.
Question: Would I be able to communicate across subnets without a layer 3 device if I could manually insert a destination MAC address in the frame header? My understanding is that the layer 2 switch is oblivious to the differing subnets, and assuming it knows the location of the destination MAC address, would forward the packet in its direction. The destination PC, seeing its IP and MAC addresses, would accept the packet, effectively letting it cross subnets without ever being routed.
A single subnet across multiple VLANs:
Broadcast traffic would be isolated to the individual VLANs. This would break ARP, as a host targeting another machine in the same subnet (but unknowingly in another VLAN) would send out an ARP request that would never be responded to.
This would effectively create separate, identical address pools for each of the VLANs, though I'm not sure how a router would differentiate between the two when interVLAN communication is attempted. I'm a little bit unsure about the pros/cons of this configuration..
Why would we ever want to do this?
Multiple subnets to a single VLAN (connected via a switch):
Hosts across both subnets would receive layer 2 broadcasts (such as ARP), > but would ignore traffic lacking an IP that targets them.
This actually has it's use case in modern DCs. Not in a way you suggest it (w/o a L3 device), but with a VEPA switch.
A single subnet across multiple VLANs:
Broadcast traffic would be isolated to the individual VLANs. This would break ARP, as a host targeting another machine in the same subnet (but unknowingly in another VLAN) would send out an ARP request that would never be responded to. This would effectively create separate, identical address pools for each of the VLANs, though I'm not sure how a router would differentiate between the two when interVLAN communication is attempted. I'm a little bit unsure about the pros/cons of this configuration..
A single subnet across multiple VLANs, also called Transparent subnet gatewaying (RFC 1027) is a somehow archaic approach. It uses Proxy ARP, but proxy ARP has it's own set of problems.
Multiple subnets to a single VLAN (connected via a switch):
Hosts across both subnets would receive layer 2 broadcasts (such as ARP), but would ignore traffic lacking an IP that targets them.
Question: Would I be able to communicate across subnets without a
layer 3 device if I could manually insert a destination MAC address in
the frame header?
You will need to replace the MAC address, and need to recalculate FCS over the whole frame, else the switch will reject it as a damaged frame. This must happen after your ethernet driver does this.
A single subnet across multiple VLANs:
Broadcast traffic would be isolated to the individual VLANs. This would break ARP, as a host targeting another machine in the same
subnet (but unknowingly in another VLAN) would send out an ARP
request that would never be responded to. This would effectively
create separate, identical address pools for each of the VLANs,
though I'm not sure how a router would differentiate between the two
when interVLAN communication is attempted. I'm a little bit unsure
about the pros/cons of this configuration..
Why would we ever want to do this?
Hosts in the same subnet would not be able to communicate with each other. Most routers will not let you assign the same network to multiple interfaces, unless they are bridged interfaces, in which case, you haven't accomplished anything except sending the traffic the long way around.
Some switches have something similar to this, called Private VLANs, where hosts can only communicate with a gateway. This is a security feature used in some situations.
I have two peer devices which are behind NAT. But the problem comes while establishing communication between them, as there are four different types of NAT and each observing a different behaviour. What can be the possible solution in this scenario?
Also I have a STUN server which is used to relay the IP addresses and port number of the peer device.
Without access to some interface with which you can configure the NAT'ing on the gateways, you can't establish a connection. Simple as that. NAT is designed to forward communication packets to the (hidden) host behind the NAT that is a) configured to get packets for that specific port or b) based on tracked connections.
Typically, this problem is overcome in SOHO routers by employing UPnP, which allows to set up port forwardings "on the fly". Knowing that this basically is the same as shutting down the firewall and exposing a PC, you won't get that in institutional networks. Your only choice then is to use a third party as kind of a broker/proxy or to use VPN technologies to "bridge" these networks (or to bring one party into the other party's network, to be more specific).
This paper has been very useful to me in order to learn about hole punching: https://www.usenix.org/legacy/event/usenix05/tech/general/full_papers/ford/ford.pdf
As last option, when you cannot do hole punching, what everybody does is the typical implementation through a server. Peer A and Peer B have a connection through a server that they can poll all the time.
I was wondering that how application like skype ( a popular chat client ) works in local network with one router, How it can listen on particular port?
for example:=
In one network A and B are two machines running skype , gateway of both is G1,
now how A and B will have same IP on internet that is of G1, but how can they ensure that they are listening on different ports? How can they ask to router G1 for unique port.
I want to make a simple text chat server on linux. How can I have connections between two different computers in two different networks?
Solution to your problem is to have a forwarding server somewhere in the net.
Different programs use different means to connect to each other. But every chat server, including Skype, has a server, which forwards data or information about subnet IP/port availability.
There are two types of clients: "listening" clients and "passive" ones. Listening clients have direct access to Internet via router port forwarding, and "passive" ones have to use additional tricks to get their hands on external data, line external servers or additional ports to listen.
The point is, not clients connect to each other, but they connect to a server, which then connects back to them to verify they are available, and, if at least one of them is not firewalled, direct another on to connect to the first one, excludint itself from further communication. And if both are firewalled, then is has to forward their messages through itself.
Host Discovery
Manual discovery, client A knowns who client B is
Discovery through broadcast UDP which is used by lot of games for LAN play. A client sends out a packet to the broadcast address for their subnet. The peers can choose to pick up this broadcast and respond. The downside is that this is limited to the current subnet. The more general INADDR_BROADCAST (255.255.255.255) works for all subnets on the local-link, but it cannot be routed, so won't work over internet (this is what DHCP auto-configuration uses).
Discovery through a central (Rendezvous) server. Each individual client knows the address of the server, and the latter informs them about each other. This technique is used by IRC, Voip, IMs and by most 'peer-to-peer' networks.
Communication
After the initial discovery is done you want to be able to talk to eachother. On the internet this can get tricky. Most people nowadays have their own router and sit behind a NAT, so direct connections are impossible.
Using a Rendezvous server, you can possibly talk to each other using the server itself. client A tells the server what to say, and it in turn tells client B, since both clients have an outbound connection to the server.
It is possible for the clients to talk to each other without the server proxying. This requires either DMZ, port forwarding or UPnP. DMZ will basically forward all incoming connections on all the ports to a given local IP. Port forwarding only forwards certain ports to local IPs. UPnP is a bit more advanced, the client requests that the router temporarily forwards a port to it, and you tell the other client via the rendezvous server where to connect.
Chatting app implementation
The easiest solution to your problem is most likely to use a central server, which is known by all the clients, that proxies host discovery and possibly the communication between the clients. If you want the clients to communicate directly, you can just proxy host discovery, and then let either DMz, manual port forwarding or UPnP do the rest.
Another solution would be to just have direct communication through NAT traversal techniques discussed above, and do manual host discovery.
Yet another solution would be to use a public webserver and 'abuse' its ability to insert content to chat with each other.
You need a central UDP Rendezvous Server.
After the initial connection from the client to the server the UDP clients can be redirected to talk to eachother directly even if firewalled.
The trick is to open an UDP connection from the inside.
Check out Real-Time Media Flow Protocol and how they use it.
Check out UDP Hole Punching
alt text http://labs.adobe.com/technologies/stratus/images/p2pvideo_250x215.jpg
Traditional NAT servers replace the source address and port with the address and a random port number of the external interface of the NAT server. This works well for simple protocols such as HTTP and SMTP, but it can create problems for more complex protocols that require multiple response ports on the external interface of the NAT server. NAT servers also aren’t aware of information stored in the data portion of the application layer header without the help of NAT editors and similar software fixes.
Windows XP’s answer to these problems is NAT Traversal, which can automatically allow the UPnP-enabled NAT client application to communicate with a UPnP NAT device. NAT Traversal provides methods to allow the UPnP client to learn the public IP address of the NAT server and to negotiate dynamically assigned port mappings for UPnP NAT client applications.
NAT Traversal features can be built into any hardware device or software application. Applications that commonly cause troubles for NAT devices but work well when UPnP-enabled include the following:
Multiplayer Internet games
Audio and video communications
Terminal Services clients and servers
Peer-to-peer file sharing applications
When these applications are UPnP-enabled, access through the Windows XP ICS allows them to work seamlessly.
Unless A and B are actually "listening" to the responses to outgoing requests, your router will need to be cofigured to forward the relevant port numbers to the relevant hosts. This isn't something that you can request in the code, it's something you need to configure on the router itself.