In our office we've got an Amazon VPC linked to our office network with a bastion server in the middle.
When I try to ping servers within the VPC it doesn't work. The answer I got from a co-worker was that "ping won't work because ICMP isn't linked in our routing configuration, only TCP."
(I can ping servers on our local business network, and Internet websites).
My question is: Why does ping use ICMP not TCP?
They belong to different layers in the OSI model.
ICMP is layer 3, for networking.
While TCP, UDP is layer 4, for transport.
Ping is echo request/reply, part of the layer 3.
there are ping utilities which use ping-like features over TCP or UDP to test whether a target host answers connection attempts. One of these is Mark Russinovich's psping (https://technet.microsoft.com/en-us/sysinternals/psping.aspx) which can use ICMP or TCP. Technically, it's not the same as ICMP as it's built upon the TCP handshake; in practice, you use it like ICMP ping.
Related
I'm new to the networking world and I'm using Wireshark to learn stuffs about the network.
I was hanging around in Wireshark while I was using my VPN for circumventing the internet filter (living in a dictatorship country).
While I was using the VPN I see packets that their source or destination IP was neither my IP nor VPN server IP.
I considered two things about my problem:
1- I know my VPN uses its VPN server to send my whole packets to that server then forward them to my deserved destination, then take the response and send it to my client (is that correct?).
2- In Wireshark, I just can see the packets that their either source or destination address is my IP address.
My packets before using VPN:
As you can see, their either source or destination IP is my IP (192.168.1.101).
After using VPN, VPN:
Wireshark:
I tried filtering packets with my IP like this ip.addr == 192.168.1.101 to see only the packets that their either source or destination IP was my private IP, and guess what? nothing was changed. Why did this happen? Wasn't that supposed to filter my packets?
I also checked those packets' MAC and compared them with my MAC, and they were identical.
So my main question is why these kinds of wandering packets were showed by Wireshark? Is my VPN client insecure and trying to sending my data to other places? Or I'm wrong about how my VPN works?
Also, I appreciate it If somebody tells me more explanation about how my VPN or Wireshark works so that I have these types of packets in my Wireshark.
First of all your considerations, point no.1 is right, that's how a typical VPN works and point no.2 is wrong.
Wireshark can capture any packet (any source IP or destination IP) flowing in and out of a network adapter technically known as NIC card. NIC cards are the way through which you can connect to a network (Internet). A quick brief of NIC over here
A typical VPN client software would form a virtual NIC to encrypt and send your traffic through it. A quick brief of VPNs over here
So, to see the required traffic in Wireshark, you must capture traffic from an appropriate interface (NIC card). The answer over here might be helpful.
I am debugging some code which is using UDP communications.
My CLIENT is behind a NAT and a Firewall.
My Server is an AWS machine on which I opened said UDP ports.
However, part of this protocol involves the server answering my client. Which I expected not to work (NAT & Firewall). To my surprise, my client is recieving packets from the server!
How is this possible? I mean, TCP (over UDP) has a concept of a connection, so I guess that the NATs and routers can associate an incomming UDP packet as a reply to an egress connection. But how (and why) does this work for a pure UDP protocol? Would my NAT/Firewall let in random UDP into my client machine?
How is this possible?
That's how NAT works. You wrote that the server is answering you client. That means that the client initiated the conversation. It doesn't matter that you're using UDP and not TCP. The NAT device still creates an appropriate mapping to let answers trough. Otherwise all UDP would have been broken behind NAT.
I mean, TCP (over UDP) has a concept of a connection, so I guess that
the NATs and routers can associate an incomming UDP packet as a reply
to an egress connection. But how (and why) does this work for a pure
UDP protocol?
The fact that UDP isn't connection-oriented is irrelevant. Sure, TCP has the concept of sessions, but both have port numbers and that's really all the NAT needs.
Would my NAT/Firewall let in random UDP into my client machine?
It's not "some random UDP". It's a UDP segment from the same IP and port number that the client sent something to.
Running on a Linux system, getting UDP packets from another computer address to let's say 192.168.0.2 from another address let's say 192.168.166.66, I can see the UDP packets coming in with tcpdump. However, if I use netcat I don't actually receive the packets.
If I create an interface on 192.168.166.XXX network, then netcat is able to receive the packets no problem.
What basic networking concept am I missing? Why do I need to have an interface on the network of the sending IP when I can see with tcpdump that they are being delivered correctly?
tcpdump per default puts the interface into promiscious mode, which lets you see all the packets arriving at your network interface. But, your operating system only processes packets destined for the local system, e.g. either having the local or a broadcast address as destination.
The final solution to this problem was to disable Reverse Path Forwarding (RPF) on the interface. There are security implications here, but after careful review this was the correct path forward in this particular case.
RPF was turned off by modifying /etc/sysctl.conf:
net.ipv4.conf.eth0.rp_filter=0
Some more information on RPF:
Wikipedia - Reverse path forwarding
Linux kernel rp_filter settings
If i established openvpn connection through udp(proto udp), can i use tcp in it(tcp convert to udp somehow), or only udp?
In short: Yes, you can send TCP through an VPN-Tunnel which is transported via UDP.
In fact you can tunnel any protocol support by OpenVPN no matter what transport you choose.
You can use any protocol you like, even raw IP. OpenVPN simulates a fully-fledged network device (to some extend – whether it's based on the Ethernet or the IP layer depends on configuration) which behaves like any other network adapter. So you can of course use TCP and UDP in it.
The packages sent via the OpenVPN devices are encrypted and passed through the UDP “connection” used by OpenVPN to the remote side, where they're decrypted and passed on to routing to forward them to their final destination (which might be the remote itself).
I understand that UDP resides on the transport layer and IP on the internet layer. I also get that they're both connectionless and unreliable. Then what is the point of UDP when we already have IP? The distinction is not very clear. Any help on this is greatly appreciated. Thanks!
Then what is the point of UDP when we already have IP?
To multiplex services. The UDP port number can differentiate between multiple services on the same host, using the same L3 identification. Using IP only it wouldn't be possible to host multiple services on the same station and easily differentiate between them.
Also, consider the case of UDP over IPv6. Since IPv6 doesn't have error-checking somebody has to perform it: the Checksum field of UDP is not optional.
Once a packet reaches a host using its IP address, the packet needs to be given to one of the applications on this machine. To determine which application should get the packet, it needs demultiplexing logic, which is based on ports. UDP has port information which is used by IP to deliver the packet to appropriate application.