When attempting to create a OPNsense VM via XO stack becomes unresponsive.
-
Hi there, working with a clean fully functional install of XCP-ng on my Host Machine, I've created a Debian 11 VM successfully..
when attempting to setup a OPNsense (PFsense) fork, using a reasonable amount of resources, I notice that during first boot/installation the VM causes the stack to become unresponsive including SSH connection to the host, occasionally I'll regain connection but it'll then drop again.
Any ideas why this is happening?
Regards,
MrXeon.
-
Hi,
Anything in the usual logs? Are you sure about the IP address? (IP conflicts?)
-
olivierlambert My XO and NFS server share their own IP Address (Same Machine), my XCP-ng Host definitely has it's own IP Address.
Not sure about the VM itself, I've added both pool wide network interfaces to it's configuration. (Eth0, Eth1) dual nics.
If that sounds correct, how should I go around checking the logs, /var/log I would assume?
-
olivierlambert It might be an IP conflict.
When removing both default pool wide network interfaces (My system has dual nics) OPNsense starts as it should.
Is the VM by chance being assigned the same IP as my XCP-ng host thus knocking out all services, how should I go around fixing this, is it a bug or user error?
-
olivierlambert Another update, perhaps it was user error... I'm not sure though..
Initially I was trying to pass the default Pool wide network interfaces, this would just end up making the host Inaccessible from XO.
When creating two new new network interfaces assigned to eth0 and eth1, under my pools network tab and attaching those to my OPNsense VM, I find that it no longer causes issues and runs as one would expect.
Is this the proper setup and I've simply made a mistake or is there something goofy going on with my system?
I will note that I defined two separate vlans for those newly created networks one labeled as WAN and the other labeled as LAN respectively...
My goal is to utilize the OPNsense VM to completely take over networking in my environment, providing internet access to other VM's and pyshcial equipment via switches/access points..
Is this the proper configuration to achieve this desired task?
-
MrXeon Well I'll correct myself regarding a few things.
Vlans aren't necessary and won't work in this scenario also there's nothing wrong with the default Pool wide network interfaces, I was simply misconfiguring them for this specific VM, OPNsense expects xn0 to be the "LAN" and xn1 to be the "WAN" thus in my case being misconfigured in the opposite order, I would assume it was trying to bind the "WAN" as "LAN" which made the services hosted on that Network interfaces via the XCP-ng host unusable...
Simply swaping these around in the order OPNsense expects fixed the issue
The only problem I've come across so far is that OPNsense can't ping the internet, where's other VM's can on that interface... so I would assume that's actually an issue with my ISP's Router behind my AP so gonna do some further testing and figure that out.
-
Any hint fohdeesha ?
-
I've solved the issue a little while back, it was definitely user error.
OPNsense expects the theoretical "LAN" to be highest priority when initializing and the theoretical "WAN" to be second..
Here a screenshot of the working method within XO...
-
Ah good to know
This is also something we usually do in our own prod: all VMs got their first NICs in the internal/mgmt network (SSH and so on) and only NICs requiring to get WAN access are using an extra NIC (so the first one is always on a LAN)
-
MrXeon So, the actual root issue here I believe, is opnsense installs come with an IP and dhcp server already assigned and enabled on the lan interface (I believe it's 192.168.1.1, but don't quote me). If your existing home network already uses 192.168.1.x/24 and already has a dhcp server, booting an opnsense install with it's virtual lan nic set to your existing home lan, there will be a lot of conflicts. Virtual nic order can be whatever you'd like (you can change and move around assignments in opnsense), but if it's preconfigured lan interface gets set to your preexisting lan network, there will be conflicts
