Topics

My opnsense running 17.7.11 crashes every 8-10 hours ( I hear the boot chime going off) and when I look in the system.log in the gui all I see is stuff like

Code Select Expand

kernel:

and

Code Select Expand

kernel: OK

just before the usual boot messages.

I gather that actual dump files aren't enabled, but I can't seem to find an option anywhere and the documentation wiki says nothing about it (search for 'crash' just gives irrelevant results).

The contents of /var/crash are a 'minfree' file that contains the string "2048". The webgui reporter says that everything is fine.

I memtested the machine, which has been running opnsense steadily since 15.x, and found no issues.

So, I have a 16.1.x install, running in a VM (xenserver). It is connected to a RFC1918 private network (192.168.5.0/24) which itself is controlled by a baremetal Opnsense install.

The VM router's private subnet is set to 192.168.15.0/24, with a LAN address of 192.168.15.1. The WAN address is a static IP 192.168.5.136.

Hosts behind the VM, on the .15.0/24 network can contact the internet just fine out of the default gateway 192.168.5.1. DNS works fine.

What I can't get working is NAT port forwards into the .15.0/24 network.

I have the RFC1918 block *disabled* on the WAN interface, so that isn't the issue.
My NAT port-forward is a WebGUI redirect in the form

WAN rule WAN address:45876 -> 192.168.15.1:443 (LAN address)

The rule doesn't work. I've examined this rule in comparison to the exact same rule I have set on my baremetal router, and they are identical. My baremetal rule works perfectly, but the VM rule does not.

I'm at a loss, I've toggled all sort of the things, and ultimately reloaded the install fresh and have applied just this rule, and no go.

The firewall appears to be working (I tried adding a ICMP pass rule so that ping against the WAN address would work), but the NAT itself is ignoring/dropping my packets.

If I use nmap to try and probe 192.168.5.136:45876 I just get back "filtered". Testing my baremetal WAN address shows the same port as open like expected, so something in the NAT/firewall is getting in the way.

I'm stumped.

edit: My NAT port forward has the TCP protocol set, but I've tried TCP/UDP as well, which didn't make a difference.

Hello,

I'm trying to install the RC in a xenserver VM, and one of the early installation commands is erroring out

"Execution of command

/usr/local/bin/cpdup -vvv -I -o /etc /mnt/etc

FAILED with a return code of 1"

I viewed the log but it didn't appear to contain anything more than what the error above already stated.

My vdisk is set to 10GB, which I assume it large enough for the non-nano installer.

Anyone run into this sort of thing before?

Greetings

I have a TAP-style OpenVPN set up, and I can ping around remotely, access LAN servers, etc. Everything seems good.

The only oddity is that while I can ping the opnsense LAN interface, I can't access the webgui in a browser.

The firewall rules for the OpenVPN server, the bridge interface, and the LAN are all completely open.

It's not really super-necessary (I can access the webgui remotely through a NAT rule) it's weird to me that I can't access it "from inside" the LAN network.

Any ideas? I can access the webgui from a local LAN machine. It's only remote hosts through the TAP that can't.