Messages

Huh, not sure that was it.  I just went to update and it didn't work again.  I went back to the DNS options and manually set the gateway for DNS servers and saved and then it updated.

So it's either 1 of these:

Randomly just decides to work
Saving DNS settings
Adding manual DNS settings
Adding gateway to DNS settings

Not sure which, I'll keep experimenting.

I found the source of the issue - someone else posted about updates just not working after using Wireguard and it turns out that Wireguard was breaking internal DNS.

After I went into System, Settings, General and unchecked "Allow DNS Server list to be overridden" and manually entered DNS servers in the networking box, it worked properly.

Now it no longer shows as orphaned and lists updates / plugins correctly.

For me it appears that when there's an active Wireguard tunnel, internal device DNS resolution isn't working.

After I went into System, Settings, General and unchecked "Allow DNS Server list to be overridden" and manually entered DNS servers in the networking box, it suddenly worked properly.

I just put together a Supermicro SYS-E200-9B to run OPNsense on.  It's a Pentium N3700 with Intel HD Graphics.

Unfortunately booting OPNsense sticks at "Booting..." after the splash screen.  I found this thread about version 19.1 and it appears to be identical.

https://forum.opnsense.org/index.php?topic=11869.0

Using the same trick of:

  set kern.vty="sc"
  boot

Worked to get it to boot.  I just wanted to pass this along that here we are over a year later and the same BSD bug is present, and immortalize it in case someone else runs into this.

This might explain why after setting up wireguard it tells me the plugin is abandoned and the first time I click update it tells me it timed out but the second time says no updates...

I can't disable the firewall on this one right now, but I'm going to build another test unit today and will see if it has the same issue as yours.

Forgive my noobishnish, but other than "check for updates" is there something I need to do to do that?

I just started using OPNsense last week due to the wireguard support and then I updated firmware again and it shows "abandoned" for the wireguard plugin.  Is this being removed or just replaced with something else? With Wireguard going 1.0 and having been audited it's just now time to start using in production.

Finally figured it out.  I had to set up both a port forwarding rule and a nat rule for it.

Port forward the individual port on the external interface, target internal server.
Then configure a nat rule on the VPN tunnel interface (wireguard for me) natting to the private lan address, but only when targeting the internal server address at the other end of the tunnel.  Downside is all traffic to that server from the local lan gets natted even though only external traffic needs it, but it works and it's very temporary.

I've just started testing OPNsense and I have to say I'm completely thrilled with it's capabilities, but for the next month unless I can figure out how to do this I can't actually deploy it at my test site.  Ultimately this won't be an issue, but if I want to go ahead and deploy this now, which I do, I need to solve this first.  Currently we run a custom iptables script on a custom linux box.

The complications / description:
I need to forward a port from an external connection to an internal server that's on the other end of a VPN.
The internal server default gateway is NOT the opnsense firewall, so it's outbound Internet traffic comes out of an entirely different city and carrier.  The internal server was recently moved, but we still have a couple of customers accessing it's old IP using a DNS name that can't be redirected elsewhere due to other services on it.  We're waiting for customers to update to a new DNS name.
To make this work currently, we do a MASQ on the packets as they exit the internal network on the current firewall, so they appear to come FROM the firewall.

So it's like this:

Customer -> OPNsense -> VPN Tunnel -> Server

To force the server to send the return packets back over the tunnel and keep it from sending out using it's own default external Internet connection, we need to MASQ incoming packets to the OPNsense firewall's internal IP.

Here's a simplified version of the rules we do this with.  I'm not asking for comments on the security implications of doing this, the destination server requires RSA keys, and this is a temporary fix for about a month while waiting for a customer to update their configs.  I'm well aware this screws with source IP logging and adds latency.

Code Select Expand

$IPTABLES -t nat -A PREROUTING -i $EXT -p tcp -d $MYEXTIP --dport 1022 -j DNAT --to-destination $INTSERVER:22
$IPTABLES -t nat -A POSTROUTING -s $INTSERVER -p tcp --sport 22 -o $EXT -j SNAT --to-source $MYEXTIP:1022
$IPTABLES -t nat -A POSTROUTING -o $INT -d $INTSERVER -j MASQUERADE


Is this even going to be possible with OPNsense?