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
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.
Setup:
The user has two applications - one sender one receiver - running on the same host/server. The user sets it up such that the sender sends messages to its own IP address not 127.0.0.1. Lets say its IP and port is x:y for simplicity. The user then sets up the receiver to receiver messages on x:y. Again this is on the same host/server.
Questions:
From my understanding this is not possible since the port will already be reserved. Therefore I cannot use the same port to try and send packets out to myself. Can I have a port used for a sender and receiver on the same node?
Is this resolved if I use SO_REUSEADDR or does this only resolve the IP conflict and not the port reuse?
If the program is not setup with IP_MULTICAST_LOOP the host will not multicast the message to itself, correct?
With IP_MULITCAST_LOOP set, if I only wanted to send the message to myself can I use 127.0.0.1 or must I use another address? Additionally, how do the ports get resolved?
If I am not seeing messages on the same node, would the first best guess be that IP_MULITCAST_LOOP is not set?
Let's take it step by step:
The sending port does not matter at all. So you can choose an arbitrary port for the sender, and use the specific port number for your service just for the receiver.
No, SO_REUSEADDR/PORT does not solve this problem. Even if you manage to achieve it: Do not start multiple listeners on the same port. This will cause strange effects. The main purpose of SO_REUSEADDR/PORT is to allow servers to create a TCP (not UDP) socket when the previous server process just died, without waiting for a timeout of the TCP state machine of the stale socket.
Corrects, assuming you mean multicast rather than broadcast,
Yes and no: If you only want to send messages to yourself you can send the packets to 127.0.0.1, and then you message will be a normal unicast packet and no longer a multicast packet, and IP_MULTICAST_LOOP does not matter at all. Multicast packets are normal UDP packets which have a destination address in the multicast address range (i.e. 224.0.0.0-239.255.255.255). The receiving socket cannot easily tell whether a packet was sent via unicast or multicast.
IP routing on the same host between interfaces is far from trivial. There are a lot of mechanisms and routing rules involved which are not shown in the normal routing table, which is just for outgoing traffic. It also depends on by which means you try to observe the messages. There is not a single point where you can see all messages going through a node (unfortunately). This is usually all attached to interfaces, and there also to an ingress and egress side, and the latter is usually not documented and not configurable. Monitoring local traffic can be tricky and may require virtual network interfaces. Really messy.
In summary: You are trying to send messages from one process to another process on the same host. Use unicast UDP for this and you are done. No multicast involved.
I have DPDK set up, with two NICs taken over by DPDK, i.e. the interfaces
are not visible to userspace applications.
Now, I need to run netperf/iperf to measure throughput performance of port-to-port
configuration of DPDK, as described here https://github.com/01org/dpdk-ovs/blob/development/docs/04_Sample_Configurations/00_Phy-Phy.md
However netperf server requires to be bound to the network interface, and netperf client
has to know the netserver's IP address. But since the interfaces were taken
by DPDK, and netperf can't see their IP addresses any longer, how could I
run tests? Is there a way to redirect netperf right in network port,
regardless of IP addressess.
iptables, ebtables.. ?
Thanks.
If you're going by that diagram, your netperf and netserver should both be on the traffic generator. On the DPDK host, traffic coming in one interface is simply routed out the other interface by OVS, and back to your generator. There are a variety of tricks to get your generator to send traffic out on the wire rather than short circuiting over loopback, but they have been addressed here already.
If what you really want to do is have netserver running on the DPDK host, then you simply need to create a virtual interface, attach it to OVS, give it an IP, and direct your netperf traffic to it.
I am trying to find out the type of the tunnel used for a vpn.. I am trying to determing if the tunnel is tcp or udp.. how do I do that? When I observe the tunnel traffic I am not able to observe anything! In the sense that packets are sent as such..
You need to observe the traffic on the physical network connection, not the traffic in the tunnel itself:
Setup a network packet capture program, such as Wireshark, to capture the traffic on the "real" network interface e.g. your cabled Ethernet connection. On Linux it would be something along the lines of eth0.
(Optional) Shutdown as many processes that use the network as possible.
Cause as much traffic through the VPN tunnel as possible - e.g. download a large file.
Watch in your capture program for any change - the tunnel traffic should now stand out due to sheer volume.
Keep in mind that if you are using an IPSec tunnel, the packets will be ESP, which is neither TCP nor UDP.
we have little network devices which are shipped with IP address 0.0.0.1 to ensure that they never collide with any other device in their new environment (thus none of the 10.x.x.x, 172.16.x.x or 192.168.x.x ranges) until configuration. DHCP is no solution since there might be no DHCP server in the field.
The devices would listen to UDP broadcasts and answer with broadcasts until they are given their new IP address this way.
This worked fine with Windows XP - but sucks with Windows 7: the config program does not receive the answer packets from the devices which still have 0.0.0.1. Wireshark sees the packets, then they are dumped by the system.
Question: Is there any reason (RFC?) that actually prohibits using this address in a local environment? Or is it just MS that was overcautious? Where can I read why they treat this address "invalid"? Which ranges are really "invalid" now, too?
Any idea of a workaround on the PC side (Win 7)?
I know that it is not recommended to use 0.xxx addresses for work places, but for this very reason - having a not-used address - it works perfectly.
Edit: there is a device out there called "Netburner" which might have faced the similar issue, according to their forum. See: http://forum.embeddedethernet.com/viewtopic.php?f=5&t=612&p=2198 Does - by coincidence - anybody know some background information?
It sounds as if your configuration application is listening for broadcast packets on all network interfaces and expecting to receive packets from foreign subnets.
That should not work - the OS should only pass-on broadcast packets from the subnets each network interface is on, not from all subnets on the same physical (e.g. Ethernet) segment. I am reasonably certain that doing otherwise is broken behaviour WRT the IP protocol.
The are two ways to deal with this:
Make sure that your network interface has an IP address in the target subnet. You can have more than one IP addresses for each network card, so that should not interfere with normal network operations.
Configure or modify you application to use raw sockets, like Wireshark. Keep in mind, however, that this overrides all normal checks and balances and should be avoided, since it can cause behaviour that is almost impossible to diagnose - which is why it is frowned upon by meny network administrators.
Can you you add new routing table entries to Windows machines easily? Windows has to know which interface to use when routing a broadcast packet to the 0.0.0.x network.
The Unix machines I'm familiar with have a routing table that maps network/netmask entries to either gateways or interfaces (if the network is a local network). The local network (192.168.0.0/16 for my home network) gets sent to interface eth0. Everything else 0.0.0.0/0 gets sent to a specific gateway machine 192.168.0.1.
If my machine sent a UDP broadcast message to network 0.0.0.0/24 (in other words, UDP broadcast sent to 0.0.0.255, then my machine would forward the packet to the gateway machine (which it can look up via arp). The switches in the middle wouldn't propagate the packet to other network devices, because the MAC address is set.
If my machine had another routing entry for 0.0.0.0/24 to the local interface, then my machine would send the packet on the wire using an ethernet broadcast group, and the switches would forward the packet to all connections. (Yay! Just like hubs in the 90s! :)
So I figure you need to add a routing entry for 0.0.0.0/24 to your client machines, so that they can properly address the broadcast packet.