Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - guywyers

#1
Hi Franco,

Can you be more specific about "more data points"? Any info I should be gathering to help you progress in this?
Obviously I would like to go to the latest version as soon as possible.

Cheers.

Guy
#2
Hi Franco,

Same here. I booted up a 23.1 from live-media to ease the rollback, but your suggestion did not solve the problem.

#4
Hi all,

I'm experiencing an issue with outgoing WAN connectivity when I upgrade to 23.1.
I did a rollback to 22.7.11 and the problems disappeared.

The problem manifests itself when I do a ping, I get a "no route to host" error.
I found some similar issues reported in the forums, but most of these users have more complicated configurations and, in any case, I tried all the suggestions given there, nothing helps.

Any idea would be welcome.

Thanks.
#5
General Discussion / Re: Network Failure
January 23, 2023, 07:02:44 PM
Yes I will do that. I had reached more or less the same conclusion, but since my network knowledge is more than rusty I thought I had overlooked something.
I will get things set up so that I have a device available to plug in the switches when it happens again. Will keep you posted. Thanks for your help so far.
#6
General Discussion / Re: Network Failure
January 23, 2023, 06:14:54 PM
Quote from: Demusman on January 23, 2023, 05:34:43 PM
If you can't ping devices on the same LAN then it's got nothing to do with the router.
The router would never even see that traffic, it's layer 2 traffic only.
So you're back to the switches being bad or cables between them.

That's exactly what I thought initially, but what's the probability of this happening, after having both of them replaced? Will try your suggestion though, you never know...

Quote from: Demusman on January 23, 2023, 05:34:43 PM
Also, try from the switches to the internet, you don't say how they're connected
It's bassically two switches with an ethernet cable between them, all drop cables arriving in ports on one of the switches and one cable between one switch and the LAN port on the router.

Come to think of it, since I cannot ping LAN devices from the router, and every device connects to the internet through the router, it would be very surprising that a ping to the internet initiated from a device connected to one of the switches would work, no? It would imply that network connectivity "device -> switch -> router" works, whereas "router -> switch -> device" does not.
#7
General Discussion / Network Failure
January 23, 2023, 04:45:10 PM
Hi all,

I'm using OPNSense in straightforward setup consisting of a wired LAN with RJ45 sockets all over my house, with drop-cables going into two connected switches and, finally, the LAN port of OPNSense connected to that same LAN. There's also WIFI, but that uses a wired Access Point connected to that same LAN, so for this issue it is not relevant.

I'm experiencing periodic network failures, not triggered by any particular event. They appear suddenly and then disappear without any concrete pattern.
I've been narrowing this down, starting by harassing my ISP, who played dumb as usual, but in this case, they really were not the cause. I came to that conclusion during one of the episodes when I logged on to the OPNSense console and discovered that pinging the outside world worked fine, but that I couldn't ping any machine on the LAN! I then tried pinging machines on the LAN from other machines on the LAN, but that didn't work either. So, during one of these episodes, my whole LAN is dead.

My next guess where the two network switches, these were indeed two old plasticky Netgear things, so I thought let's replace them: didn't solve the problem.

I ruled out the drop cables, because the probability that all of them went bad at the same time is zero.

In terms of cables there were two potential single points of failure: the cable between the OPNSense and the LAN switch and the cable linking the two switches together. I replaced both: didn't solve the problem.

That leaves one potential issue that I can think of: a faulty network port on my OPNSense box (hardware issue). So here I have some questions:

  • Is there a way to diagnose this? I mean, are there logs where a faulty network port would leave traces? One thing I have noticed is that the usual message about interface down/interface up, which appears when you unplug a cable, DOES NOT appear on the console when one these episodes happen.
  • Is it possible that such a failure would cause my whole LAN to fall over? I can understand that losing connection to the Firewall implies a loss of internet connection, but shouldn't the internal LAN keep functioning?


Finally, I have a more general question: aAre there any recommendations or tools to help me diagnose this issue?

Any help would be greatly appreciated, because this is driving me nuts.

Thanks
#8
Thanks guys.

I changed the mirror and was able to perform the update.

However I couldn't recall the fact that I had ever selected a download mirror and when I went to the location indicated, there was no specific mirror mentioned. It simply showed "(default)".

I did change it to some explicit location and got the update done, but it does seem strange to me. No?
#9
I performed an upgrade from the 19.7 to the 19.7.7 version and I'm getting stuck during the upgrade with the system showing exactly the same behaviour as shown here (https://forum.opnsense.org/index.php?topic=10689.msg48752#msg48752) and here (https://forum.opnsense.org/index.php?topic=10386.0). Concretely:

  • The update hangs for a long time ("Updating... Please wait")
  • Web gui is no longer accessible, even after a long time, showing error "403 Forbidden"
  • Console access is no longer possible, showing error message mentioned above: "sh: /usr/local/sbin/opnsense-auth: not found"
  • Reboot completely turns the device unresponsive

Recovery consists of a clean install from (19.7) installation media (USB in my case) with a recovery of my configuration.

Any ideas what's happening and how I can fix this?

Thanks.
#10
19.1 Legacy Series / Re: LDAP + OTP AUthentication
March 03, 2019, 04:48:20 PM
Thanks, but the question is how do I get to see the QR code?

Say I have a user "johny" defined somewhere with the info accessible through LDAP. Where can I assign johny his initial OTP seed?
Should I explicitly add johny as a user? This seems strange, because in the simple LDAP scenario (without OTP) I can at least import users from the LDAP.
#11
19.1 Legacy Series / LDAP + OTP AUthentication
March 03, 2019, 12:55:56 PM
Just upgraded to 19.2 and was delighted to find LDAP + 2FA authentication.

I succeeded in setting up a server (LDAP + Timebased One Time Password), but now I'm stuck in the next step:

How do I set up the OTP seeds for these LDAP users?

At first I thought I would have to import them as for normal LDAP users, but that doesn't seem possible. Did I overlook something?

Thanks for your help.
#12
I had this working too in a config with openvpn on a standalone linux box.

I even patched two openvpn plugins (https://github.com/threerings/openvpn-auth-ldap and https://github.com/evgeny-gridasov/openvpn-otp) to get it to work.

Although I'm a huge fan of OpnSense, I never succeeded in getting this to work and would love to see it on the feature list.

For it to work, the password that is returned from the client needs to be processed in a specific way. This in turn requires the authentication module (whatever that is) to 1/ be aware that it is not the usual password it is receiving and 2/ to do the specific processing to split up the normal password and the otp reply.
#13
Hey guys,

Just started configuring OPNsense on a new hardware config and run into the problem documented here: https://forums.freebsd.org/threads/59627
It's not life threatening but annoying, because it means that every time you do a shutdown, the system hangs in the last phase of the power-off and requires a physical power-off/power-on cycle to get back in the normal state.
This is definitely a pain if you do reboots as a consequence of configuration changes.
As explained in the link above, the FreeBSD workaround is to use  shutdown -r now and they also mention that the problem is fixed in FreeBSD 11.1.

So, seeing that this beta contains FreeBSD 11.1, I installed it and indeed the problem is fixed. Just wanted to bring it up in case other people run in to this.

Cheers.