Messages

[very]

I have recently setup a new OPNSense (24.1.10_3) router to replace a failing router which ran OpenWRT.

After getting everything up and running perfectly last week (including a number of VLANs) I have just configured Wireguard to use my VPN-vendor account using the WG Selective Routing to External VPN Endpoint instructions available in the docs.

Various tests show the WG instance to be working and not leaking my real IP address and in general things are working well.

However, I now have 2 fairly significant new problems:

• If i turn off (disable) Wireguard at /ui/wireguard/general, then no PCs within the VLANs which are "normally" in the Wireguard tunnel can browse the internet.
  
  It is not just a DNS problem as I can not even open a website for which I know the IP address.
  
  It's weird to me as I have NOT implemented the "killswitch" instructions, yet disabling Wireguard kills the connection entirely.
  
  


• Port forwarding does not work within the WG tunnel (even though those handful of ports are forwarded at the VPN provider).  [ This in spite of changing various parameters of the forwarded ports (especially the "destination address" which should likely no longer be "WAN address" but now likely the VPN address). ]

Ports for one of the machines are somehow forwarded to/from the actual WAN address which has me very confused since the port forwarding setup is identical for another machine in the same VLAN and its ports are not all thusly forwarded when there is an exact correspondence in setup with the exception of IP address (one digit different) and a port number (also 1 digit different).

Given my efforts regarding problem 2 haven't worked out in the least, these problems likely point to firewall configuration issues.

I have played with reordering some of the rules (there are not yet many) to no avail.

Any and all ideas are appreciated!  Thanks in advance.

Problem 1 is the more important one; if I can figure out a way to kill the WG instance without killing the internet, that would be good.

Problem 2 is really only for torrenting anonymously where desired -- not hugely important at the moment.

Hi @brinm00

Thanks marjohn56, this put me on the right track. It works beautifully now - can control my Logitech server from within my guest VLAN.

Could you please provide details on how you setup your firewall rules to successfully achieve this?

I am struggling with my Squeezebox finding its Logitech Media Server across VLANs.  I have it detailed in a separate thread since this one has been inactive since Dec. 18 . . . but perhaps tagging you directly will get this post some notice.

Thanks in advance.

[The Aliases used for Squeezebox ports and devices have been reviewed to be correct!]

Hi OPNSense Gurus!  ;)

I have recently begun implementing VLANs to great effect (using OPNSense 23.7.12).  Everything works well (although my firewall rules are still quite permissive while working through it, so I am not really surprised at things working in general).

One of my VLANs -- VLAN6 -- is for "entertainment devices."

On VLAN6 I have a Logitech Squeezebox which successfully pulls its DHCP reserved IP address (10.11.6.10).  It needs to make a UDP broadcast on port 3483 to find the LogitechMediaServer (10.11.1.100) which serves music.

Since VLANs won't pass UDP packets across the VLAN boundary, I thought I could use port forwarding (which I otherwise successfully use for remote access of a couple PCs on the network).  Unfortunately this does not work for reasons unclear to me.

Attached are images of what the NAT and LAN firewall rules look like for it, as well as the port forwarding setup (this may somehow be in error -- my experience with port forwards in OPNSense to date as been letting WAN requests into specific computers).  The Aliases used for Squeezebox ports and devices have been reviewed to be correct!

Finally, I have attached a screenshot of my attempt to setup the "UDP Broadcast Relay" plugin.  FYI: when it was enabled, the port forward was disabled (and vice-versa) so there should be no "trampling" going on.  Also, I tried both with and without enabling "TTL for ID."

You will note in the background this same relay is highlighted in green.  This seems to indicate the relay is running.  When the relay is NOT running there is a corresponding error in the general log.

There is neither a broadcast/multicast address nor a source address entered as those two things seem to cause the relay to fail startup.  Also, @marjohn56 specifically mentioned leaving those blank in relation to Squeezebox / LMS setups in this linked post

In the case of attempting the "UDP Broadcast Relay" solution, I have a "wide open" floating firewall rule which bidirectionally passes any and all tcp/udp packets to ALL sources and destinations on the single 3483 "discovery" port used by Squeezeboxen.  Just in case, I have an additional floating FW rule which passes all traffic on port 9000 to ALL sources and destinations (LMS requires this for streaming, but it should nt be required for discovery).

Anyway, with this (temporary) level of "openness," I am surprised I can not get this to work!  [I can't show the FW rules as I do not have ability to attach another image . . . ]

I am posting this here because the thread for UPD Broadcast Relay is "stuck" on an unanswered question on Dec. 18, more than one month ago.

Any and all hints would be appreciated.  I am probably doing something really dorky and fully expect to facepalm when I hear back!  :-[

[Additional input from OPNSense gurus still sought! TIA]

WRT @Demusman 's DNS idea, there may be something to it.

This installation has all Windows (10, Pro) machines.  Who knows if some upgrade (possibly automagically applied over the weekend) caused a DNS configuration change?!

Interestingly, the many other OPNSense upgrades I performed yesterday all have Linux devices attached -- with no complaints of internet connectivity.

That said, I doubt that a DNS configuration issue would cause me to no longer have remote access.  Then again, I have witnessed Windows close off ports like that for RDP right after upgrades were applied.

I'll have a user in the office check some related settings tomorrow morning.


Additional input from OPNSense gurus still sought!  TIA

Hi @Demusman

Can you ping anything on the internet?
Could just be a DNS problem.

From OPNSense-Router-attached devices, NO.

From within OPNSense itself (using the applet at /diag_ping.php ), yes.

[off]

I updated a number of OPNSense 22.7.6 instances yesterday night by remote connection.  All upgrades were "successful."

One installation, however, now has no devices which can connect to the internet.  Meanwhile, I can still connect to the router remotely and can see all expected devices listed in /status_dhcp_leases.php.  However, I can not connect to any of those machines by VNC, SSH or other methods for which ports are open.

This sounds like a firewall configuration problem (although I changed nothing before or after the upgrade!), so i turned it off (temporarily).  I did this at /system_advanced_firewall.php under Miscellaneous/"Disable all packet filtering."  [ I recognize this is a "bazooka"-type, acceptable for quick testing-only "solution," but the devices could still NOT connect out nor I in. ]

I started worrying that the modem was doing something weird, but having a user at the facility connect a computer directly to the modem immediately enables internet access via that (i.e. directly connected) device (Arris SB6183, basically a "dumb" device which allows for essentially no end-user configuration; the modem is at the same exact hardware and software revisions as other installations which are working fine under OPNSense 22.7.8).

OPNSense health check indicates no problems . . .

Code Select Expand

***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 22.7.8 (amd64/OpenSSL) at Mon Nov 21 13:31:12 PST 2022
>>> Check installed kernel version
Version 22.7.7 is correct.
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 22.7.7 is correct.
>>> Check for missing or altered base files
No problems detected.
>>> Check installed repositories
OPNsense
>>> Check installed plugins
os-ddclient 1.9_1
os-wireguard 1.13_1
os-wol 2.4_1
>>> Check locked packages
No locks found.
>>> Check for missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages: .......... done
>>> Check for core packages consistency
Core package "opnsense" has 63 dependencies to check.
Checking packages: ................................................................. done
***DONE***


Any and all ideas would be most welcome.

Thank you in advance!!

[Ooops!]

It took me a while to figure out the Username issue as various other DynDNS update clientsI have used have treated this a bit differently!

Hopefully this will help future searchers with any challenges using OpnSense with NameCheap dynamic DNS services.

Ooops!

os-ddclient seems to have an issue when NameCheap has the wrong IP address but the OPNSense location has not experienced an IP change.

I rolled out OPNSense to a number of friends and clients based on my (very positive) experience over the past month.

To make rollout quicker, I pulled a backup of installation #1 to each of the other OPNSense locations (making changes to the config as appropriate rather than hand configuring every little thing . . .

In one instance (let's call it "installation X"), I forgot to unplug the router from the WAN and the os-ddclient immediately updated the my NameCheap account with the "correct" IP address to the wrong hostname.

IOW, installation 1 took on the IP address of installation X.

A day or two later when trying to access installation 1 remotely, I was now accessing "installation X" (pretty confusing for the first couple minutes!)

At installation 1, os-ddclient reports

Code Select Expand

Notice ddclient[61265] 63162 - [meta sequenceId="1"] SUCCESS: my-hostname: skipped: IP address was already set to www.xxx.yyy.zzz

At installation 1, the IP address had not changed . . . but at NC, the IP address was NOT, in fact "already set to" it.

It is, of course, trivial to update NameCheap manually (to "resynchronize" the IP address with the hostname at NameCheap), but os-ddclient should really have a more robust mechanism to check whether the dyndns service reflects the reality of the WAN address one is trying to report!

How does anyone else handle this?

Meanwhile, I guess I will report this at https://github.com/opnsense/plugins/issues

[so I presume this then qualifies as a bug]

Hi @franco!

Local database setting is irrelevant since, yes, it is the default.

OK, so I presume this then qualifies as a bug since the ONLY thing I changed to finally be able to SSH log in as root was to change from "nothing" to "local database" (which as we both agree is supposed to be the "same").

Where do I best submit a suspected bug?

Do the OpnSense developers monitor this forum closely or is it best to post on Github: https://github.com/opnsense/core/issues

Perhaps somewhere else?

Thanks again for you help!   :)

Now that I have SSH access as root, I am wondering how to gain sudo for my names user so that I can access the opnsense-shell on login.

It seems that enabling option 2 in the screenshot in my prior post has done this?

The named user can now

Code Select Expand

sudo reboot

Is that as definitive as it seems?   :-\

[I now have SSH access for root.]

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

Thank you for the additional info.

Hey!  I now have SSH access for root.

I may have discovered a bug.

At

Code Select Expand

System: Settings: Administration

I changed Authentication:Server from "nothing" to "local database" (#1 in screenshot) even though that is supposed to be the default if "nothing" is selected.

The ONLY other change I had made was to Authentication:Sudo to "ask password" (#2 in screenshot).  That change, however only conceptually affects a sudo request once logged in.

With regard to SSH access, I have noticed that in:

Code Select Expand

System: Access: Groups

There is nothing which indicates an ability to select "SSH" or shell access or similar.

So too in

Code Select Expand

System: Access: Users

I can not edit "Effective Privileges" to include anything indicating I would be able to login in any sort of text mode (although one user can).

The lack of such options contravenes @franco's help from 2015 in the post: https://forum.opnsense.org/index.php?topic=1930.msg6008#msg6008

Granted, it is 6.5 years later and things have changed, but the fact I can not find similar settings is a bit puzzling.

I have also checked plugins and packages for anything obviously missing but am not seeing anything jump out.

Hi @franco

Not sure how you end up being locked out, because you don't say what you are doing, what your setup is: e.g. VMs may have strange behaviour during reconfigure of IPs and so on and so forth.

This is installed "on metal" (not VM).  It is a ultra-small form factor PC based on Intel Celeron J4125 with just two NICs, one bound to WAN, the other to LAN.  All host connections are handled by a NetGear 24-port switch which is (of course) attached to the OpnSense LAN port.


FYI, I did not do anything which could be construed to cause a lockout this 2nd time.  No editing of firewall rules, no work with VLANs, etc.  The only thing I had done was to press save after reviewing the root user's settings (which had not changed, but I wanted to "confirm" those settings, hoping SSH login would become enabled).

In the case of this 2nd lockup, I decided to reboot the machine and could then immediately again log into the web interface.  Perhaps earlier clearing the Firefox cache did not actually achieve anything (the successful login there happened to be about 9 hours after the lockout).

BTW, during each "lockout" I could still connect to other hosts on the network and also browse the internet.

During the second lockout I also "successfully" SSHed in, but could not reboot because of a lack of permissions.

I should mention, the first time I finally got back in I immediately updated to 22.1.6 . . .

Just in case this would solve anything.


Also, is there any way to upload a text-based OpnSense config file here (redacted of passwords and other sensitive info) so that any forum gurus can review for massive configuration errors?

Hi @franco


Meanwhile, I am "locked out" of the web interface again.  No login page, endless wait . . .  [ this time it is definitely not Firefox.  I have cleared cache, etc. ]

Personally I'm using non-root user and "sudo su" after having Sudo configured as required in the same GUI page.

Non-root users can use opnsense-shell, but the features it uses will be only partially available since they alter administrative settings

Because of the new "lockout" I SSHed in as the named user.  Alas, can not even reboot as I do not have sudo permission for that user.  Your input above seems exactly on point.

Alas, I can not get in to change it!  Grrrr.

Hi @franco

It turns out the shell specified for the named user was /sbin/nologin

When I changed that, I was able to SSH in.

However, the shell is not automatically present the helpful "console" I have seen a couple times on initial installation and configuration of OpnSense.

The root user should get that (i.e. I presume that is what is referred to by  /usr/localsbin/opnsense-shell )

Alas:

• that shell is not available to the named user from the dropdown (nor can I manually type it in)
• I still can not SSH in as root

Trying to SSH / login as root, I get the following:

Code Select Expand


Password:
Password:
Password:
root@192.168.1.1's password:
Permission denied, please try again.

Meanwhile, everything seems primed for SSH login by Root.  [ See attached screenshot. ]

Anti-lockout and SSH listening capabilities can be tricky depending on interface layout and specific SSH settings used. Anti-lockout is bound to LAN by default, but can move to another device if interfaces were removed or reassigned. On LAN you also have default allow rules, but on other interfaces you have not, so if the anti-lockout is on the wrong interface and the rule is not in place it couldn't possibly work.

This rule has moved to NAT as I opened various ports for remote management of OpnSense a couple important machines on the network and access to their services.

Remote (i.e. from WAN) access via SSH was also not possible.  Web access was also attempted and it failed.  My remote user did not have time to clear Firefox cache to attempt another login . . .