Is there a problem using VMware on Windows to host a virtual linux box running iptables? I have a configuration that seems to work on physical hardware but is flaky under VMware.
I'm using VMware to run a virtual linux 2.6.24 machine on a Windows 2003 Server host. The linux application is essentially a NATting router that runs iptables. The rules in the nat table include:
Chain foo_pre
target prot opt in out source destination
LOG all -- * * 0.0.0.0/0 0.0.0.0/0 [options here]
LOG all -- * * 0.0.0.0/0 10.10.1.33 [options here]
DNAT all -- * * 0.0.0.0/0 10.10.1.33 tcp dpt:80 to:192.168.0.33:8080
Chain PREROUTING
target prot opt in out source destination
foo_pre all -- * * 0.0.0.0/0 0.0.0.0/0
I'm seeing the incoming packets to 10.10.1.33:80 using tcpdump, and the first LOG generates messages, but neither the DNAT or the second LOG show the packets registering on their packet counters, the second LOG generates no messages, and tcpdump doesn't show the packets to 192.168.0.33.
The eth0 adapter is on the 10.10.0.0/16 network with a default gateway of 10.10.1.1; it has a secondary address of 10.10.1.33/32. /proc/sys/net/ipv4/config/eth0/forwarding is set to 1.
Is VMware the culprit, or am I missing something? Thanks!
Update: we've simplified the test environment. No NAT rules at all, just a linux VM running under a Win2k3 Server host. Test steps:
VM is bridged to host NIC. VM and host are on the same subnet, with the same default gateway as above.
VM communicates with devices both on and off its subnet: ICMP, TCP, UDP. Communication is bidirectional: it doesn't matter which equipment initiates it.
Engineer power-cycled the default gateway while poking at the system.
VM now communicates only with devices on its subnet. Any attempt to communicate through the gateway to the same equipment from Step 2 fails to put packets on the wire. tcpdump on eth0 on the VM shows outgoing packets with no response; WireShark on the host shows nothing on the physical NIC.
Stopping and restarting the VM does not change its behavior. Stopping the VM and replacing it with a different VM with appropriate IP address, etc. does not change the behavior.
The Win2k3 host continues to communicate normally, both on and off its subnet.
I can only conclude from this that "something happens" between the VM and the host: in the VMware drivers, or in the host's network stacks. I'm off to scour the web again.... it's hard to imagine we're the first to observe this.
Updates as they come. Thanks for your thoughts and discussion.
Your second log line is trying to match packets sent to 10.10.1.33, but you changed the destination address to 192.168.0.33 on the line above it.
I'm not sure why you don't see the outgoing packets in tcpdump yet. I assume you're running tcpdump on the linux VM itself. Is the VM sending packets on the same interface it's receiving, or is there a second virtual ethernet adapter? What machines are the various IP addresses assigned to (other than 10.10.1.33).
Regarding update:
I gather you're not using DHCP (people usually don't bother when using static IP addresses). Also, it sounds like the gateway sees one NIC using two IP addresses. Normally that should be ok, but it's always the details that get you.
Is it possible the gateway will only assign one IP address to the NIC and is ignoring traffic from the VM?
After your edit, I suggest an experiment: on your physical machine, configure your NIC to disable all hardware acceleration.
Related
There are 2 NICs in my Windows-based machine, the IP address of one of NICs is 192.168.1.x/24 and the other one is 192.168.2.x/24. The Windows-based machine run an application that need to send out the multicast packet 229.255.10.1 through two of the NIC. However, the multicast packet 229.255.10.1 can be sent out from the NIC 192.168.1.x/24 only. Can I use route add -p Windows Command to send out the multicast packet from the NIC 192.168.2.x/24?
I think you can use:
route -p add 229.255.10.1 mask 255.255.255.255 192.168.2.x metric 1
where 192.168.2.x is your IP on nic 2
It remains only a problem that I haven't found a solution yet: if your application send a packet before you add the root, you need to reboot PC. This is a problem if the second NIC is, for example, a VPN client and it starts after the application
I am using a Juniper firewall device that our incoming internet connection receives, then a switch that connects a bunch of servers that is connected to the firewall.
For some reason, some of the traffic between the hosts connected to the switch are showing up as sessions on the Juniper firewall. The hosts are using the same network address. I thought the traffic should be strictly going through the switch to other host, not out to the firewall and then back to the switch then the host.
I created a test environment, with a small switch, and the traffic between the hosts did not show up on the firewall sessions.
Is there anything particular to the Cisco SG200-50 that would cause traffic bound from one port to another, same network address, to be sent out to the firewall before switching the traffic to the other port?
The switch will not be looking at the layer-3 packet, it only delivers known unicasts to the port where the destination MAC address is located. It will flood unknown unicasts and broadcasts to all switch ports, including the router. To the switch, the router is just another host.
I have seen this when one or more hosts have either an incorrect mask or an incorrect gateway configured.
I have a REST service running on Mac OS X, which im currently accessing using "localhost:8888" and "10.0.2.2:8888"
I want to access the same service from another computer which is in the same network.
I disabled the firewall also and I typed
nc -v 192.168.1.3 8888
and got the result as
nc: connectx to 192.168.1.3 port 8888 (tcp) failed: Connection refused
currently i use localhost (to access using java application) and 10.0.2.2 (to access using android application runs in the simulator) which both runs on the same machine which the server runs too.
I want to put the android application to my phone and give the machine ip addess ( because if i connect to internet via wifi, it'll be in the same local area network) i should be able to access my service runs on my machine.
can some one please tell me what im doing wrong here? Thank you
You can't access localhost from your front end code. It needs to refer to the server's name or address.
The localhost address should be 127.0.0.1, which is in the loopback range of addresses. Any address in the 127.0.0.0/8 block can never appear anywhere on any network, nor can any address in that block be used as a source or destination address outside a host. It is not possible for one host to access anything in that address range on another host.
The goes back at least as far as RFC 990, ASSIGNED NUMBERS:
The class A network number 127 is assigned the "loopback" function,
that is, a datagram sent by a higher level protocol to a network 127
address should loop back inside the host. No datagram "sent" to a
network 127 address should ever appear on any network anywhere.
RFC 1122, Requirements for Internet Hosts -- Communication Layers:
(g) { 127, }
Internal host loopback address. Addresses of this form MUST NOT
appear outside a host.
Also RFC 3330, Special-Use IPv4 Addresses:
127.0.0.0/8 - This block is assigned for use as the Internet host loopback address. A datagram sent by a higher level protocol to an
address anywhere within this block should loop back inside the host.
This is ordinarily implemented using only 127.0.0.1/32 for loopback,
but no addresses within this block should ever appear on any network
anywhere [RFC1700, page 5].
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
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.