OSX disables firewall while running Virtual PC

Ifrit

Ifrit

Registered
I use the shared IP adress setting in Virtual PC in order to access the Internet. ("virtual switch" option is broken in Tiger)
(still need VP for some P2P clients and software which is only available for the Windows platform)

While running virtual PC I tried to set the ports in the Sharing preference pane in order to enable access for p2p clients in Virtual PC.

Suddenly the Firewall tab in greyed out and a message appears that a firewall (I assume third party) is already running. But in fact, it isn't.
If I close Virtual PC and start the sharing preference pane again, the OSX firewall is enabled.

Personally I believe this is a security risk.

Secondly, if the firewall is disabled this way it seems that the ports you opened are closed again, so certain software can not access the network.

edit:

Another "bug" I encountered:

If you open certain ports with "New..." in > Sharing > firewall (settings) and select as service "others" and enter tcp and udp ports you want to open while the Firewall is disabled, OSX doesn't remember your settings.

You have to enable (and if you don't need it > disable) the firewall, then the settings will "stick".
 
Is your mac directly connected to the WAN or over a router? If a router is inbetween, I would not worry for any such things and simply turn off the software firewalls. However, it's an interesting finding. Do you have the software firewall of windows running over VPC activated?
 
I am not directly connected to the internet (I use a router + the router's firewall) so I don't care that much.

The firewall in the guest OS (Windows XP, service pack 2) is already disabled.

Another finding:

I seem to be unable to access the mac's smb shares if the file and directory sharing is enabled in Virtual PC's guest OS and if it is connected to the network.
 
IT makes sense that the firewall is turned off in that situation. Effectively what is going on is that the virtual pc is sniffing traffic for its IP. The normal system firewall would block all the traffic for the virtual machine before it could reach the application. It is not a bug but rather a consequence of the networking mode you have chosen. I know you can't use the virtual switch which is really the right thing to do, so I am not blaming you or anything like that.
 
The odd behaviour is, that OSX turns the build in firewall off without informing the user, which I think isn't a nice thing to do.
 
It is Virtual PC that turns it off and not OSX. That is why you got the 3rd party firewall message, because a 3rd party turned off the firewall.
 
Yes, I'd consider this a bug. Can anybody confirm/deny that the same happened or not under Panther?
 
There is actually an article on securityfocus about packet sniffing as a means to defeat firewalls. I'll not link to it because it was a very silly article overall. However the gist of it was that you can sniff packets even with the firewall enabled - libpcap (used in VMWare) captures the packets before the firewall examines them.

Now, what mechanism VirtualPC uses, I don't know - the point is that that's not the only mechanism there is, and it ought to be possible to work this without disabling the firewall.
 
scruffy said:
However the gist of it was that you can sniff packets even with the firewall enabled - libpcap (used in VMWare) captures the packets before the firewall examines them.

Now, what mechanism VirtualPC uses, I don't know - the point is that that's not the only mechanism there is, and it ought to be possible to work this without disabling the firewall.
Click to expand...

There is some confusion in this thread about what is the general problem and what is the specific problem in this situation.

In the VMWare case mentioned above and the way VirtualPC works when using the "virtual switch" a special driver is loaded that acts like a fake network device. This kernel driver sits right above the networking hardware and can process every packet before it hits the firewall. In this case this works just like you said.

The specific problem here is that the network code changed and now the previous technique used to hook into the network stack no longer works. The necessary kernel modules no longer work.

The fallback technique that is being used by VirtualPC addresses the problem from the application perspective and does not use a kernel driver. One effect of this is that as an application the network packets must travel through the normal channel and survive the firewall. Since the IP address is for the VM of course they will not survive. The most expedient option in this case is to just turn off the firewall -- with all the problems that entails.

So who is to blame? Apple changed the network stack but Microsoft did have access to the beta releases so yell at whomever you please.

-Eric
 
You must log in or register to reply here.
Back
Top