dmesg reveals a series of drops of the printer (192.168.5.5) trying to reach the virtual machine guest (192.168.5.24).
[ 8207.414111] SFW2-FWDint-DROP-DEFLT IN=wlan0 OUT=wlan0 MAC=e0:2a:82:e1:d5:21:00:22:64:3b:99:99:08:00 SRC=192.168.5.5 DST=192.168.5.24 LEN=425 TOS=0x00 PREC=0x00 TTL=63 ID=3204 PROTO=UDP SPT=427 DPT=427 LEN=405
So fire up yast2 firewall. I then:
• Ensured the WiFi adapter is in the Internal zone
• Explicitly added 192.168.5.0/24 (both TCP and UDP) to the Internal zone
• Explicitly adding TCP/UDP port 427 as both SPT and DPT
• Explicitly allow the printer, VM guest, source port (SPT) and destination port (DPT) as custom rules.
Nope, no change despite being told explicitly to allow these things. Twilight zone...
OK, try shutting down the VM.
OK! This stops the drops from happening. So the problem is with the VB, not the firewall.
https://forums.virtualbox.org/viewtopic.php?f=6&t=43072
suggests that bridging is the issue. It states the problem should not exist but occasionally arises. This affirms my twilight zone observation...
OK, we check VirtualBox and indeed, wlan0 is bridged. So we change it to Natural Address Translation (NAT) and restart. And, indeed, the drops have now stopped.
So it would appear that the firewall looks not only at IP addresses and ports but also at MAC addresses, and if they don't all match correctly then the packet is dropped. VirtualBox does indeed modulate the guest MAC address under bridging. Changing back to NAT resolved the issue.
The disadvantage of NAT mode is that, much like a private network behind a router, the virtual machine is invisible and unreachable from the outside internet. Similarly, neither the host nor any other machine on the local network can see into the VM guest. The VM guest (now 10.0.2.15) is on a completely separate network from the host and the LAN.
But now it's working so we'll leave it NAT until we find a reason to work harder...
So now back to trying to fix the printer...
No comments:
Post a Comment