Re: vmware and bridged host

Sorry for not answering before, but I could not work on this project
for a while.

Jack Snodgrass ha scritto:

On Fri, 22 Sep 2006 13:02:22 -0700, falesca wrote:

I've run vmplayer, vmware workstation, and vmware server.
I've got them running on 6 different servers, all using
bridged networking. No issues on any of them.

all I've ever had to do was run vmware-config.pl, make
sure that the vmnet-bridge process starts and it's all good.

the guest is configured to use the pcnet32 ethernet device,
sets up for DHCP or a static IP Address and it routes
directly on the hosts network.

pcnet32 with fixed address


My hosts has ( private network ) an address of 192.168.1.1.
The vmware guests have addresses of 192.168.1.2 and 192.168.1.5.
arp shows a different mac address for each IP Address.

I assume your stuff is setup in the same network address space....


yes they are in the same network address space (but i don't see why it
should be a problem to have host and guest on different networks as
they are bridged, maybe apart from talking to each other)

Here there may be the issue... se below.


I ping'ed from guest machine an external machine, but i don't receive
any icmp message . I have a switched network so it's not a routing
problem.

But it occours to me now that i could check the switch forwarding
tables of the switch to see if my guest os mac address is registered.

There is no firewall or selinux active

I just noticed that there is no vmnet0 device appearing with ifconfig
on the host, but i thought it was normal because the pcnet32 interface
is bridged on the eth0 of the host.

no net devices will register...

ps -aef | grep vmnet-bridge
should show you something like:
root 2492 1 0 Sep20 ? 00:00:00 /usr/bin/vmnet-bridge -d /var/run/vmnet-bridge-0.pid /dev/vmnet0 eth0
if the device is not present when the guest boots, it will
detect it and give you an error. When you guest boots, you
should see an icon for the ethernet device and be able to
disable it or enable it.


This is present
root 6311 0.0 0.0 1300 220 pts/1 S 12:57 0:00
/usr/bin/vmnet-bridge -d /var/run/vmnet-bridge-0.pid /dev/vmnet0 eth0


you should be able to run tcpdump on both the guest
and the host for the 'briged' ethernet device and see
the systems sending data.


I see in fact the icmp traffic on eth0 of the host and the guest

arp -n on both the host and guest should show each others
info...

arp -n | grep eth0
192.168.1.25 ether 00:12:17:FD:CC:70 C eth0
192.168.1.5 ether 00:0C:29:3E:E2:35 C eth0
192.168.1.2 ether 00:0C:6E:4B:1F:70 C eth0
192.168.1.15 ether 00:50:8D:86:07:4D C eth0
192.168.1.21 ether 00:0C:29:C4:AC:90 C eth0

the .5 and .21 boxes are vmware guests....

on a vmware guests....
arp -n
Address HWtype HWaddress Flags Mask Iface
192.168.1.15 ether 00:50:8D:86:07:4D C eth0
192.168.1.1 ether 00:13:D3:C1:D4:51 C eth0

for grins... on the guest...
ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:0C:29:C4:AC:90
inet addr:192.168.1.21 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fec4:ac90/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:440184 errors:0 dropped:0 overruns:0 frame:0
TX packets:414161 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:131452843 (125.3 MiB) TX bytes:76571523 (73.0 MiB)
Interrupt:177 Base address:0x1080


about the same thing

[root@websrvr ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0

In my case... the host ( 192.168.1.1 ) is also the firewall, but my
guest does not have issues talking to other boxes in my network.


The problem could be here.
I used as gateway for the def route the gateway of the subnet... that
is NOT the host
The host is 192.168.21.23 and the gateway is an external router with ip
192.168.21.254

Being the interfaces of guest-host bridged together (layer 2 link), I
thought the host doesn't have to be a router for the guest os.
am I wrong?

Not sure what else it can be other than an iptables issue.
iptables is off for sure

.

Relevant Pages

  • Re: ESX Vmware Physically connected to different segments
    ... If something like this is found, I'm optimistic that someone will provide a xen patch (if not then we watch for people taking advantage of that exploit, maybe installing KLM in guest systems, no windows guests, etc). ... host specifically. ... virtualization techniques that allow for greater use of the devices we ... While there are fun ways to attack network vlans to ...
    (Pen-Test)
  • Re: networking w two win xp home w/ sp2
    ... guest cannot see host. ... >>i have gotten network to work. ... There are 1 servers in domain MSHOME on transport ...
    (microsoft.public.windowsxp.network_web)
  • Re: networking w two win xp home w/ sp2
    ... >>>netwrok setup host can see and get files from guest and use internet through ... guest cannot see host. ... >>>i have gotten network to work. ...
    (microsoft.public.windowsxp.network_web)
  • Re: vmware and bridged host
    ... the guest is configured to use the pcnet32 ethernet device, ... My hosts has (private network) an address of 192.168.1.1. ... should be a problem to have host and guest on different networks as ... on the host, but i thought it was normal because the pcnet32 interface ...
    (comp.os.linux.networking)
  • Re: ESX Vmware Physically connected to different segments
    ... Yes it does make you think twice when considering such a design, however I am not familiar with exploits at a guest domain that would effect the host specifically. ... Now if someone has code available the detail attacks on guests effecting hosts (DOS not included, exploits taking control of services of a host from a guest, or accessing network or resources not setup for that guest), then please post them to the list so we can discuss the issues and how to address them. ... These same questions might also be applied to VLANs or other types of virtualization techniques that allow for greater use of the devices we have available. ...
    (Pen-Test)