Date: Sun, 25 Mar 2001 10:43:31 -0500 From: The Babbler <bts@babbleon.org> To: freebsd-emulation@freebsd.org Subject: [Fwd: Re: VMware networking (was: Slooow VMware on RELENG_4 SMP)] Message-ID: <3ABE1223.F5FDD1CD@babbleon.org>
next in thread | raw e-mail | index | archive | help
I got the list name wrong the first time, so I'm trying this again.
-------- Original Message --------
Subject: Re: VMware networking (was: Slooow VMware on RELENG_4 SMP)
Date: Sun, 25 Mar 2001 01:45:20 -0500
From: The Babbler <bts@babbleon.org>
Organization: None to speak of
To: Julian Elischer <julian@elischer.org>,
freebsd-emulation@freebsd.org,Brian.Dean@sas.com
References: <20010324150145.A9587@tortugas.irbs.com>
<3ABD6D4D.DC46FB87@babbleon.org> <3ABD8421.EC5438F9@elischer.org>
Julian Elischer wrote:
>
> The Babbler wrote:
> >
> > I haven't tracked it down, but I am also getting a vmware message that
> > claims that the root disk is mounted remotely, thoug this is not the
> > case. I haven't noticed terribly performance problems, but I really
> > haven't done anything with vmware but bring it up and try to ping. (I
> > can't get the #@$! networking right for vmware under FreeBSD--I'm really
> > seriously considering giving up & going back to Linux in fact.)
>
> I have had no (zero/nada/none/zilch) problems with routed networking..
> I've also seen others having no problems with bridged networking..
>
> what are you trying to do?
>
> I use vmware-1.0.4 (I have a licence and don't really feel like paying
> to upgrade) to run
> 1/ win98 for turbotax
> 2/ FreeBSD-current for kernel debugging.
>
> >
>
> --
> __--_|\ Julian Elischer
> / \ julian@elischer.org
> ( OZ ) World tour 2000-2001
> ---> X_.---._/
> v
Well, I've tried a number of things (and posted about some of them
before). For what it's worth, I am running vmware 2. (It was free for
me [owing to the date when I purchased my vmware1 license], so it was an
easy decision. Performance improvements for Win 98 were quite
noticable.)
I have vmware running a 192.168.242 network ("...242" for short), with
..242.2 being the vmware and ...242.1 being the vmnet1 node.
I have another interface on the host, which varies. At home (which is
what I'm trying to get working first), it's on a 192.158.147 network
("...147" for short). ep0 is ...147.4 and its gateway is ...147.1.
I run a local nameserver on the host. All this is so that the guest
O/Ss can use a simple static setup regardless of where the host is,
since the host is a laptop and it isn't always in the same place or at
the same address. The guest is configured with ...242.2 as its IP
address, ...242.1 as its gateway, and ...242.1 as its nameserver.
The primary guest of interest is Windows 98, though I briefly had a
FreeBSD guest when I was running Linux and would hope to have a Linux
guest how that I'm running FreeBSD, and perhaps a -CURRENT FreeBSD as
well.
So . . . .
With the latest vmware2 port (2.0.3.799_1), which is supposed to "just
work" by using netgraph, I can't even communicate from the guest to the
host at all. Not even from ...242.1 to ...242.2 or vice versa.
Actually, it's a little weirder than that. The *first* time I tried
this after installing that port, it all worked beautifully. But after
the next time I rebooted my host, it didn't work at all, and it never
has since then either.
So I reverted back to the previous vmare2 port (2.0.3.799). From there
I can ping from the guest (...242.2) to the host vmware (...242.1) as
well as to the host's "real" addr (...147.4), but I cannot access the
host's gateway (...147.1). I *can* access the host's nameserver via
...242.1, so if from the guest I do something like "ping www.yahoo.com"
then the numeric IP address to ping will be correctly resolved, but the
packets won't actually get delivered.
I tried solving this under 4.2-RELEASE by enabling bridging the in the
kernel, but that broke my networking with my 3com PCMCIA card
*completely*--my *host* was no longer able to reach its gateway, so
obviously my guest couldn't either, and I was pretty much dead in the
water. I have since solved *that* problem by upgrading to 4.3-BETA,
where I can enable briding in the kernel, and the host networking works
just great, but I still can't get the guest packets anyplace. However,
I will be perfectly frank in confessing that I'm not at all clear on how
bridging is really supposed to work here.
It's built into the kenel, and sysctl shows that net.link.ether.bridge
is 1, and I get messages about setting the interfaces into promiscuous
mode, but the ep0 interface, if I do ifconfig, doesn't actually show
itself as being in promiscuous mode. This could be the root of the
problem, or it could be that the bridging is trying to set up too early,
and PCMCIA intialization is realatively late. But I have tried using
sysctl to turn the bridging off and back on, and that didn't fix
anything.
The bridging man page does talk about using bridging whilst enabling IP
forwarding, which logically might be required since they are two
separate networks, but I can't figure out how one combines the two
concepts of bridging and IP forwarding or how to write the rules under
such a circumstance. Also, the briding man page has a warning that
having both interfaces have IP addresses is bad, so this might be why
things are broken for me.
So, having written gotten firewalls working for both Linux and FreeBSD
for my real firewall machine, and having solved this problem under Linux
with "IP Masquerading" (Linuxese for IP network address translation), I
ditched the bridging (this was still with 4.2-RELEASE) and tried to
write a zero-security mini-firewall isntead.
I disabled bridging the kernel and enabled the IPFIREWALL and IPDIVERT
along with the IPFIREWALL_DEFAULT_TO_ACCEPT option (since I'm not
looking for security at this level).
In then tried a wide variety of firewalls. First I tried the OPEN
firewall, then the SIMPLE firewall with
oif="ep0"
onet="192.168.147.0"
omask="255.255.255.0"
oip="192.168.147.4"
# set these to your inside interface network and netmask and ip
iif="vmnet1"
inet="192.168.242.0"
imask="255.255.255.0"
iip="192.168.242.1"
I tried both of these with and without this:
natd_enable="YES"
natd_interface="ep0"
and then my own custom firewall with this set of rules:
oif="ep0"
oparms=`/sbin/ifconfig ${oif} | /usr/bin/grep inet | /usr/bin/cut
-f2,4,6 -d' '`
oip=`/bin/echo "${oparms}" | cut -f1 -d' '`
onet="${oip}"
omask=`/bin/echo "${oparms}" | cut -f2 -d' '`
obcast=`/bin/echo "${oparms}" | cut -f3 -d' '`
iif="vmnet1"
iparms=`/sbin/ifconfig ${iif} | /usr/bin/grep inet | /usr/bin/cut
-f2,4,6 -d' '`
iip=`/bin/echo "${iparms}" | cut -f1 -d' '`
inet="${iip}"
imask=`/bin/echo "${iparms}" | cut -f2 -d' '`
ibcast=`/bin/echo "${iparms}" | cut -f3 -d' '`
fwcmd=/sbin/ipfw
${fwcmd} -f flush
# Use NAT to translate packets destined to or coming from the outside
${fwcmd} add divert natd all from ${inet}:${imask} to any via ${oif}
# Allow all normal traffic--we are inside the real firewall
${fwcmd} add allow ip from any to any
Now, under Linux I had all this working, with the guest set up in the
same manner (indeed, I just brought the virtual disk over from Linux),
and these rules in Linuxese. The above was my (incompetent, I fear)
attempt to translate them into BSDish. In case anybody reading this is
bilingual, here it is in the original language. This scripts works.
extip="`/sbin/ifconfig eth0 | grep "inet addr" | awk '{print $2}' |
sed -e 's/.*://'`"
extint="eth0"
intnet="192.168.242.1/24"
intint="vmnet1"
echo extip=$extip
echo extint=$extint
echo intnet=$intnet
echo intint=$intint
# The rest of this is lifted comments & all, from the masquarading
howto.
# MASQ timeouts
#
# 2 hrs timeout for TCP session timeouts
# 10 sec timeout for traffic after the TCP/IP "FIN" packet is
received
# 60 sec timeout for UDP traffic (MASQ'ed ICQ users must enable a
30sec firewall
# timeout in ICQ itself)
#
ipchains -M -S 7200 10 60
ipchains -F input
ipchains -P input ACCEPT
ipchains -F output
ipchains -P output ACCEPT
#############################################################################
# Forwarding, flush and set default policy of deny. Actually the
default policy
# is irrelevant because there is a catch all rule with deny and log.
#
ipchains -F forward
ipchains -P forward DENY
# Masquerade from local net on local interface to anywhere.
#
ipchains -A forward -i $extint -s $intnet -d 0.0.0.0/0 -j MASQ
# catch all rule, all other forwarding is denied and logged. pity
there is no
# log option on the policy but this does the job instead.
#
ipchains -A forward -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT
--
"Brian, the man from babble-on" bts@babbleon.org
Brian T. Schellenberger http://www.babbleon.org
Support http://www.eff.org. Support decss defendents.
Support http://www.programming-freedom.org. Boycott amazon.com.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-emulation" in the body of the message
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-emulation" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3ABE1223.F5FDD1CD>