I have a tiny problem, I guess it’s just something that I’m overlooking but I cannot seem to find the solution.
My laptop runs on linux but from time to time I need to use some Windows-tools. So to make it easy, I run a Windows-VM inside VMWare Workstaiton Player (the free version), which works pretty good.
The network-configuration is
so the VM has it’s own IP-address.
In the WUI of IPFire everything regarding the VM is shown correctly, the IP-adress is correct, the MAC-adress is correct, that it’s in the BLUE-network is correct (because the laptop itself is connected via WLAN), etc. I also activated AccessOnBlue for the VM.
But whatever I configure, IPFire blocks the traffic coming from the VM, more precisely it blocks the DNS requests the VM is sending to the IPFire-address on BLUE (because it’s the DNS-Server). IPFire also blocks the packets from the VM to the broadcast (in the same network). I even tried to change the DNS for the VM (changed from 192.168.2.1/IPFire to 192.168.0.1/FritzBox) but then IPFire blocks the forwarding.
I tried applying rules for the whole BLUE-network and for just the IP-address of the VM, I even changed the standard-configuration of the firewall, so that IPFire does not block forwarding pakets, but still everything from the VM is blocked.
Blue access requires two things, a Mac address identifier and an IP address. Can you check that you have a separate MAC address for the VM and that the IP address shown in that table is also the address that the VM gets from IPFire DHCP?
Once I changed the DHCP allocation range, and I forgot to update that table. It took me several days of staring at the logs before I finally activated my brain cells and corrected the IP address in Blue Access.
thanks for your reply! I checked again and everything seems to be correct. This is what ipconfig in the VM tells me (192.168.2.1 is the IPFire’s address in BLUE).
And the IP-address and MAC-address are definitely different from the ones of the host.
After all the firewall is “recognizing” the VM correctly, because it successfully blocks all the DNS-requests as I can see it in the logs… still don’t know why.
I wanted to dig out this one because I still got this problem and maybe someone has some more ideas.
Summary:
Laptop with a VM running on it (VMware Player).
Laptop is connected over Wifi with IPFire, it’s in the BLUE zone, everything is running fine.
Laptop IP is: 192.168.2.20
VM gets its (different from the host) IP from IPFire, so communication between VM and IPFire is possible, DHCP is working. MAC-address and IP ist listed in the DHCP of IPFire.
VM IP is: 192.168.2.23
MAC / IP of the VM is also listed in “access on blue” (active) and I also allowed the VM (for testing purpose) to go “everywhere”, so it has acces to RED on all ports for example.
But still IPFire is blocking the DNS-requests from the VM. I first wanted the VM to use IPFire as DNS (IPFire IP is: 192.168.2.1). Then I tried using an “outside” DNS like 8.8.8.8 but that did not work either.
you cant use ip replication methods as mac address tracking is deployed in the system since the VM has its own MAC address. So the VM must either be nat through the host machine or manually set with an ip address from the blue’s network outside the DHCP pool.
In the setup where I need a VM on a Laptop with different “access rights” than the host, I just switch to FritzBox-Wifi… With bridged network FritzBox recognizes them as different devices and every one has it’s own rights.
I just guess that IPFire is just “too smart” and FritzBox you can trick.
I really don’t know why people want to do something like this on blue, which is designed for isolated wifi and where they need to do this is on green or orange.
Well its one thing, you are trying to use a network that is predefined to be isolated. So you need to do this where the system allows it (green or orange) instead of trying to rip apart the blue security for this one device.
Well… yeah… too bad that I have a powerful laptop on which I want to use VMs… just a stupid idea… better put wifi into green… no… bad idea too… or just wire you whole home… oh no… bad idea too… better use a completely different firewall/gateway/router which is capable of this… oh no… bla bla bla
