Running as a test system in VM, can't access hosts on LAN?

Started by Stilez, December 28, 2020, 06:50:04 PM

Previous topic - Next topic
I'm running a slightly unusual situation that *should* be easy,and I've installed OPNSense dozens of times, but I'm failing every time on this, and I've run out of ideas what I'm missing.


I want to test some dev things on OPNSense - doesnt really matter what. So I don't need it operational, I just need a bare install with internet and LAN access.  My LAN is IPv4 with a flat desktop switch using 10.0.0.0/9, so I installed using VMWare Workstation and the OPNSense install ISO (set at FreeBSD 12 x64 guest).


After first reboot I set WAN = em0/DHCP and no LAN (which according to the console menu would trigger full firewalling mode). It assigned 0.0.0.0. Fail. DHCP works on every other LAN device, but this wasn't picking up an IP. I checked with TCPDUMP on the main ("real") router and in its logs, I can see ARP who-has and replies, and DHCP discovery/offer as expected. But the VM OPNSense wasn't picking them up.


This isn't to do with name resolution, as it gets "host unreachable/down" even on IP pings.


So I set WAN as a static 10.x.x.x/9 IP, which let me into the Web UI from my desktop. I used the Web UI to create manual rules to pass all IPv4inward (and for avoidance of doubt, outbound) on WAN, then within the web UI, I set WAN to DHCP and disabled RFC1918 blocking (thanks Bart, forgot to mention this first time, just rechecked and it was unchecked) - and it still wasn't able to pick up an IP.



       
  • It's definitely got access from the LAN, so networking is fine - I can reach the web UI.
  • I can see DHCPDISCOVER/DHCPOFFER in my main router's DHCP log, and ARP who-has and replies via tcpdump on the LAN
  • RFC1918 is unchecked on WAN
  • The vm install can't ping anything, including the main router/DHCP server, even though other LAN devices can, and the ARP replies seen via tcpduymp aren't showing in its arp cache (arp -a)
What could be going on?


More generally, whats the simplest way to run OPNSense in a vm and have it able to communicate to the internet?


If needed, the config has no sensitive data and I can attach it. But I'm hoping there is an obvious answer Im missing.

Interfaces, WAN interface, untick 'block private networks'

OPNsense disallows RFC 1918 address ranges on its public interface by default.

Bart...

Quote from: bartjsmit on December 29, 2020, 09:59:48 AM
Interfaces, WAN interface, untick 'block private networks'

OPNsense disallows RFC 1918 address ranges on its public interface by default.
It's already unblocked, though I forgot to say so. Just rechecked, and added a mention to OP for clarity.
It's not that..... hence my confusion. What else could it be?

Hi,

Just to be on the save side here as you haven't mention your VM configuration:
Did you set the virtual network card of your VM to bridged mode?

Soko

Yes - and there can't be a question about connectivity at a network level.  See attached.  I'm getting DCHP requests and responses at my main router, and ARP requests and responses picked up at my fileserver, as well as responsiveness from my browser to the Web UI on the host PC.


More than that, "tcpdump -i em0 -vv" on the OPNSeense console shows it's seeing the arp replies ("arp is-at" from other LAN devices,  but when I type arp -a, they aren't in that list, it asks again.

The IPs mentioned - 10.5.100.85 is the arbitrary IP offered by DHCP, that isn't working because it's not received, and 10.22.46.5 is the static IP I set on WAN in the Web UI, that is working to the extent mentioned.

arp -a and ifconfig confirm that the ARP replies and DHCP replies arent being received by the OPNSense router. And yet, firewall log is empty, RFC1918 is unchecked, and inbound "pass all" rules are set and activated on the WAN.


(More screenshots in next post)

(More...)

Pfuhhh... beats me than unfortunately.
I'm running OPNsense in a VM too and everything works out fine. At the beginning I've had DHCP enabled on the LAN side as well. Now I'm running static IPs.