Is it possible that set a proxy for windows (7) and all packets go Through the proxy server ? I mean all packets even ARP packets !
Sure it is take a look at arp spoofing/poisoning basically arp protocol works by machine saying this is my IP address and the router takes note and forwards any packets with this IP to that machine (Mac Address). SO basically you have to send out the arp messages at a faster rate tricking the router that messages should be bound to your machine and not the actual mac address that IP should belong to.
just to note (arp is a LAN protocol) so if your proxy is not within the the subnet as the machine your presumably attacking their is no way you can get these packets
Related
I am constructing an ip-ip tunnel between remote linux server and the local windows server.
The windows server does not support raw ip-ip tunnel so I develop a simple app which makes usage of wintun.
Said the local windows server is bound to ip_local, the remote linux server is bound to ip_remote, and the tunnel ip is ip_tun.
Currently, the windows server can receive the incoming packet (outer ip_remote->ip_local, inner ip_client->ip_tun) from the remote linux server in the tunnel.
For the outgoing packet (ip_tun->ip_client), if I route the packet to the tun NIC, the packet can be sent out.
However, if I route the packet to the real NIC, the packet is ignored.
Thus there seems a mechanism that blocks the sending of packets when the source ip is not bound to the corresponding NIC.
(In the above case, because ip_tun is not bound to the real NIC, the outgoing packet is ignore.)
Is there any configuration that can disable such mechanism?
Thanks for any help.
Enable ip routing in registry then everything ok.
I have an application that is very simple. It sends out UDP packets to a client somewhere else on the network.
The host computer is 192.168.11.66 (Windows 10), the client device is 192.168.11.65 (proprietary device).
The host pc cannot see the client device, however I know that it is on and listening to traffic. When I send UDP packets from the host, I use Wireshark and I do not see the packets being sent out. Instead I see messages from ARP trying to locate the client. I assume because ARP is unsuccessful, the host cancels the sending of the packets.
If I change the destination address of the packets to a broadcast address, all of the packets get sent and I see everything on Wireshark. I need to be able to specify the IP address of the client and have Windows send the packets regardless of whether or not it thinks the client device is on the network or not. The client device looks for UDP traffic specifically addressed to itself and the client device has no way of making itself visible on the network.
Does anyone know how to work around this?
Thank you #Remy: instead to create your own ARP record manually. – Remy Lebeau
I did not realize that I could create manual entries in the ARP. I need to read more about ARP. Adding a manual entry solved my issue. I found that you could do it using ASP -s, or add neighbor using NETSH .
Thanks!
For various reasons, I'm trying to construct and send raw TCP packets to a remote host (ex. google.com) with raw sockets. I'm trying to use pcap, so the raw socket code can be ported to Windows at some point.
Looks pretty straightforward...
1. ethernet header
2. ip header
3. tcp header
4. segment (optional)
2,3,4 are straightforward. #1 is the rub because I don't know what to use for the destination MAC address of google.com. From what I can tell, ARP is useless for telling me that MAC because I have to be connected to google's router for it to work. Snag.
So that makes me ask this question:
Should I use the MAC of MY router as the destination MAC address in the ethernet header when sending to a host not in LAN? And when the packet is forwarded, does every router it hits tear out that Ethernet header and replace it with the appropriate source/destination MACs so it gets to Google.com? That is the only thing that sounds reasonable.
Side note, I think this was the motivation here, but the question never quite made it:
how to determinate destination MAC address
That's right. The source MAC address in the ethernet header should be the MAC address of the interface you're sending from, and the destination MAC address should be your router's MAC on its interface that is connected to your LAN.
It's important to remember that Link-Layer addresses are used within networks (in this case, both your MAC address and your router's internal interface are on your LAN), while Network Layer (IPv4/IPv6) addressing is used to route your packet from the source host to the destination host (this is ignoring NAT and a whole bunch of other grossness that arises in IPv4).
What will happen when you send your Ethernet frame out of your interface is the following:
Your router will end up with the frame after it travels through 0 or more switches, which know where your router's internal MAC address is from receiving traffic from it in the past. Your router knows the frame is for it because its internal MAC address is the destination MAC.
Your router will strip off the Ethernet header. Then, it will inspect the destination IP address, and determine how to forward that packet based on that address. If we're talking about your home router, it is probably also changing the source IP address (something called Network Address Translation, or NAT), but since it isn't in the scope of your question I'll leave that alone.
Before it forwards the packet to the next router on the path toward the destination IP address, the router needs to put another Link-Layer header back on the IP datagram because it stripped off the one you had put on it. So, it will create a new Link-Layer header using its outgoing interface's MAC address as the source MAC, and the MAC address of the next router's internal MAC address as the destination. In this way, the Link-Layer header is re-written "hop-by-hop".
Somedays before even I faced the same confusion. So long story short yes the destination MAC address will be the gateway router MAC address. And about how I determined is - like this -
I used the command
route -n
Then I used the command
arp -n
The output is as you can see -
goutbose#####:~$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.39.51.1 0.0.0.0 UG 0 0 0 enp2s0f0
goutbose####:~$ arp -n
Address HWtype HWaddress Flags Mask Iface
10.39.51.130 ether 00:1a:c5:01:12:94 C enp2s0f0
Now you can hardcode your destination MAC in your packets as I did as an easy hack or if you want you can design your own ARP resolution which is way out of my knowledge scope to help you out. My implementation to implement my own ICMP ping request using raw sockets is as follows -
https://github.com/Goutam1511/Socket-Programming-with-C/blob/master/myping.c
Although a late reply I hope it may help somebody else out because there are very little resources related to using raw socket in the link layer.
If I have a UDP server repeatedly receiving requests from the same client machine, when might the client's incoming IP address change even though the user is actually still on the same machine and has not done anything deliberate to change her IP address?
I can think of two cases: (1) packets are coming in via proxy servers that use a pool of different IP addresses, and (2) the client machine is using a dynamically assigned IP address that has expired and been reassigned to a new IP address.
Are there any other cases?
Is it a mobile client? If so, it could change networks. For example -
A phone switching b/w 3G and wi-fi
A laptop changes wi-fi networks (this is infrequent though)
Is there a way to find out the IP address of a device that is directly connected to a specific ethernet interface? I.e. given one host, one wired ethernet connection and one second host connected to this wired connection, which layer or protocol below IP could be used to find this out.
I would also be comfortable with a Windows-only solution using some Windows-API function or callback.
(I know that the real way to do this would probably via DHCP, but this is about discovering a legacy device.)
Mmh ... there are many ways.
I answer another network discovery question, and I write a little getting started.
Some tcpip stacks reply to icmp broadcasts.
So you can try a PING to your network broadcast address.
For example, you have ip 192.168.1.1 and subnet 255.255.255.0
ping 192.168.1.255
stop the ping after 5 seconds
watch the devices replies : arp -a
Note : on step 3. you get the lists of the MAC-to-IP cached entries, so there are also the hosts in your subnet you exchange data to in the last minutes, even if they don't reply to icmp_get.
Note (2) : now I am on linux. I am not sure, but it can be windows doesn't reply to icm_get via broadcast.
Is it the only one device attached to your pc ?
Is it a router or another simple pc ?
To use DHCP, you'd have to run a DHCP server on the primary and a client on the secondary; the primary could then query the server to find out what address it handed out. Probably overkill.
I can't help you with Windows directly. On Unix, the "arp" command will tell you what IP addresses are known to be attached to the local ethernet segment. Windows will have this same information (since it's a core part of the IP/Ethernet interface) but I don't know how you get at it.
Of course, the networking stack will only know about the other host if it has previously seen traffic from it. You may have to first send a broadcast packet on the interface to elicit some sort of response and thus populate the local ARP table.
Windows 7 has the arp command within it.
arp -a should show you the static and dynamic type interfaces connected to your system.
Your Best Approach is to install Wireshark, reboot the device wait for the TCP/UDP stream , broadcasts will announce the IP address for both Ethernet ports
This is especially useful when the device connected does not have DHCP Client enabled, then you can go from there.
You can also get information from directly connected networking devices, such as network switches with LDWin, a portable and free Windows program published on github:
http://www.sysadmit.com/2016/11/windows-como-saber-la-ip-del-switch-al-que-estoy-conectado.html
LDWin supports the following methods of link discovery: CDP (Cisco Discovery Protocol) and LLDP (Link Layer Discovery Protocol).
You can obtain the model, management IP, VLAN identifier, Port identifier, firmware version, etc.