I have this setup of systems where 3 VMs are connected to OVS.
On one system I am running UDP server on VM1 and VM3 and UDP client VM2.
In VM2, the packets from UDP client are destined to VM1 (destination address and port as mentioned in the code). But at the OVS, I have provided the rule where if the source IP is VM2 and destination is VM1, I am redirecting the UDP packets to VM3.
I am able to see the counter matching the rule and even I have observed the change of destination and port at the interface of the new destination in the wireshark.
But the problem is the I am not able to read the packets in the UDP server program in VM3
Can any one help please
EDIT : The below is the screen shot when trying to redirect packets from a TCP connection. I am not able to send the packet to the destination
For the virtual machine's networking stack to accept those redirected packets, you will have to rewrite the destination IP and Ethernet addresses as well.
Related
I am forwarding some outgoing TCP traffic on LAN (eventually UDP as well) to a local (transparent) proxy server before sending them out on the internet. The packets are forwared correctly it seems, I can see the SYN's in Wireshark.
The problem is that accept() bound to a port X doesn't accept a connection with destination port X and a destination IP different from the proxy server's own IP it seems, which was something I expected.
Is there a way around this in Winsock or in Linux sockets? How can I achieve the accept() or similar?
Linux sockets have the option IP_TRANSPARENT. See the linux man page ip:
IP_TRANSPARENT (since Linux 2.6.24)
Setting this boolean option enables transparent proxying on
this socket. This socket option allows the calling
application to bind to a nonlocal IP address and operate both
as a client and a server with the foreign address as the local
endpoint. ...
As far as I know the option is not available for windows sockets.
I am new to PCAP file format. Does the file have the routing information regarding the routing from the src ip to the destination ip?
I am to know if routing is going through a specific route and how often?
Does the file have the routing information regarding the routing from the src ip to the destination ip?
Not in general.
The file has packets taken directly from the network, so, for example, if you captured an IP packet on an Ethernet, it would have the Ethernet source and destination addresses, which are the Ethernet address of the machine that sent the packet on that network and the Ethernet address of the machine on that network to which it was sent, and the IP source and destination addresses, which are the IP address of the machine that originally sent the packet and the IP address of the machine to which the packet is ultimately being sent.
The Ethernet addresses give the source and destination of one particular routing hop; the other routing hop information is not, in general, available.
The only way in which you'd have some routing information would be if the IPv4 header had the "record route" option, in which case each host that routed the packet would add its IP address to the list of IP addresses in that option. However, packets only very rarely have that option (and you'd probably have to modify the program sending the packet in order for it to have that option!) and, if the packet does have that option, it will only show the hosts through which the packet has already been routed, not the hosts through which the packet will next be routed on the path to the destination host.
If you want to know the routing path from a given IP address to another IP address, you'd need to use the traceroute command on UN*X, or the tracert command on Windows, on the source host, and hope that it works (the packets it sends might not cause the appropriate ICMP Time Exceeded Message message to be send back; traceroute and tracert depend on it being sent).
I'm new in this site.
This is my problem: I have 3 different sources (IP: 192.168.1.1,192.168.1.2 and 192.168.1.3) that send data (via UDP) to a single receiver (IP 192.168.1.4) on the listening port 8900 (same port for every source). I can redirect the traffic on 3 different listenging port on the receiver (one for every source i.e. 192.168.1.1 --> port 8910, 192.168.1.2 -->8920 and 192.168.1.3 --> 8930), 3 processes are listening on those ports.
If i loose a packet during the transmission, the process that should have been received this packet, try to send a retransmission request to the sender that is wrongly localhost instead of the original sender.
Is there a way to maintain the orinal IP during the redirection?
Sorry for my bad English and thanks for your help.
getsockopt(...,SO_ORIGINAL_DST) is what you are looking for.
(assuming that you did iptables -j REDIRECT or similar )
Say I have a router with IP 42.98.1.70, with 2 NiCs connected to it with IPs 192.168.1.200 and 192.168.1.300. The router has port forwarding on port 10433 to redirect packets to 192.168.1.200. The routers internal network IP is 192.168.1.100.
When NIC 192.168.1.300 sends a packet to socket 42.98.1.70:10433. the host 192.168.1.200 gets a packet from socket 192.168.1.100:48900, which as far as I know, looks like a hole punched socket setup by the router.
So theoretically, if host 192.168.1.200 replies with a packet to socket 192.168.1.100:48900, that packet should eventually get back to host 192.168.1.300, since the router should bridge the two via its internal table mapping, aka 'UDP hole punching'.
However, the packet sent back to 192.168.1.100:48900 from 192.168.1.200 never reaches 192.168.1.300.
i'm suspecting that what could be going on is that UDP hole punching doesn't work in between NICs on the same network. It only works between a source that is external to the network and one that is within it. Is that the case?
After reading this RFC - https://www.rfc-editor.org/rfc/rfc5128, it looks like what i was trying to do is called "hair pinning". Although some routers support it, not all do. Apparently mine is one of those.
Say you have a router with external ip 42.1.98.9, with the port 10443 set to forward all incoming TCP/UDP packets to host 192.168.1.200. The routers internal network address is 192.168.1.100.
say there are two NICs connected to the router, with internal IP 192.168.1.200 and 192.168.1.300.
I've noticed that packets sent to socket 42.1.98.9:10443 gets redirected to 192.168.1.200, which is the expected behaviour.
However, say the computer 192.168.1.300 sends a packet to socket 192.168.100:10443. In other words a computer from inside the network is sending a packet to the router, in a port that should theoretically redirect incoming packets.
On that scenario, I'm not noticing the packets being redirected to the proper host -- 192.168.1.200.
Why is that? Does port forward on the router occur only for packets being sent to its external IP address?
Thanks
Yes, generally port forwarding is only from the external address to internal addresses. I'm guessing a commercial-grade router could be programmed to do what you want, but not any home router I've ever seen.
You should be able to use the router's external address from inside the network though (i.e., send packets from 192.168.1.300 to 42.1.98.9:10443 and it should redirect to 192.168.1.200:10443).