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 - mfld-pub

#1
Had two test instances on development branch. One was 25.1_b19 and the other was b20.

Set branch to community and let it do its thing. Both rebooted after the update and now reject GUI credentials and SSH keys.

Was I supposed to run another update while still on development branch ? What is the recommended process to get from a 25.1 beta revision to 25.1 release ? Simply toggling the branch definitely did not go well :)

Only encountered this on upgrades from beta. 24.7.12_4 -> 25.1 updates are going well, currently I am 5 over 5 successful updates.

Edit: 25.1.r_38 to 25.1 works fine just toggling to from dev to community branch. It's just the earlier betas that die.

Edit2: I simply reset root password in single user mode and found the system running 24.7.12_4. Ran the updater again and both instances came up on 25.1 successfully. Maybe coming from an early beta broke  something that was needed for "The access management was rewritten in MVC"

#2
General Discussion / Re: About Business License
April 23, 2024, 06:25:04 PM
Quote from: rickygm on April 23, 2024, 02:06:30 AM
Now that I'm seeing this message, I don't know whether to wait for version 24

AFAIK the 23.7 license key will also work for 24.x so there is no need to wait. I just got an additional license checked out and it took 1 minute. Now on 23.7.x business I do not expect the key to die when 24.x business releases.
#3
General Discussion / Re: os-rfc2136 - documentation?
August 14, 2023, 03:27:27 PM
+1

Using both the dyndns plugin and the acme validation method for RFC2136. It is an important feature to us.
#4
What part of the update process fails for you ?

Mine seems to work. Downloads all, unpacks and installs/reinstalls package but reboots back into 22.1.b_141 and then offers me the update again. Default repo, Development branch.


Package name    Current version    New version    Required action    Repository
packages   22.1.b_141   22.1.b3   upgrade   OPNsense
#5
Quote from: fabian on July 07, 2021, 09:10:00 PM
The port was not changed. The only thing in the hotfix was a little issue in a diagnostics page.

On the topic of diagnostics page: For 21.1.8 the Diagnostics and info pages are blank for me.
#6
Super strange... I checked the

/usr/local/etc/tor/torrc

And it is right there as it should be:

DirPort 8080

#7
Strange. I update two more Opnsense 21.1.7 -> 21.1.8 and they also stopped publishing DirPort.

I now have 3 out of 4 TOR relays on 21.1.8, one is still on 21.1.7. Settings in OPNsense are:

(see attached)

You can see here the upgraded nodes all stopped publishing DirPort:

(see attached)

I changed settings by changing to a different port number and back to 8080 to try force it to rewrite the config. Also rebooted. No dice. All nodes that upgraded to 21.1.8 lost DirPort.

Edit: Somehow the screenshots I embedded had weird scaling issues. Attached the .png instead
#8
Upgrading from 21.1.7 to 21.1.8 updates the tor plugin. After updating and rebooting I notice that the Directory Port is no longer advertised. Has anyone else seen this today ?

I can see that metrics.torproject.org shows "0" for my directory port. In the config in OpnSense it is set correctly. Did not touch the config. Only change I initiated was 21.1.7 to 21.1.8 update.
#9
QuoteAnd the change to OPNsense is every little trouble worth...

100%. Enjoying it so far. Only thing holding me back is https://github.com/opnsense/plugins/issues/1972 BGP and it is a bit worrying that under "Advanced Options" in places where you could put a configuration blob to overcome UI limitations they state
QuoteThis option will be removed in the future due to being insecure by nature. In the mean time only full administrators are allowed to change this setting.
But there are things that would break horribly the moment you take away that box, i.e. https://github.com/opnsense/core/issues/2048

#10
QuoteFirewall > Settings > Advanced > Disable reply-to [check]

Dude!!! I am up!

The crossover from pfSense to OPNsense is full of pitfalls LOL. Thank you so much!

Why is this a thing though and why only in some environments ? I set up a few OPNsense migrations this month and only now came across this.
#11
Just noticed there is a 21.1.7_1 point release out.

Release notes don't show anything that could be related to my issue but I thought I might get lucky. 

I applied it and although it didn't ask me to I rebooted for good measure. Issue persists.
#12
Hey all,

Super weird. I have installed OPNsense 21.1.7 on bare metal. IPv4 and IPv6 WAN assignments are static /29  and /64. IPv6 gateway is the ::1 of my /64. IPv6 WAN address is the ::2 of my IPv6 prefix.

I.e. WAN address: 2001:DB8:1212:3000::2/64, Gateway address 2001:DB8:1212:3000::1

OPNsense can make outbound connections over IPv6 just fine. But inbound only ICMP works.

For testing, I disabled Block Bogons and Block Private on WAN. Now I made some inbound rules on WAN:

allow ICMP (v4/v6) from any
allow TCP/22, TCP/443 IPv4 from an alias and log it.
allow TCP/22, TCP/443 IPv6 from an alias and log it.

I checked the alias table and it has been populated with the expected IPv6 addresses.

Now when I connect from a whitelisted address to OPNsense over IPv6 on tcp/443 or tcp/22 I can see the firewall logging the allow. But no connectivity can take place.

It just times out.

For testing I took everything out of the equation, no blocking of RFC1918, no blocking of BOGON, and put an allow rule as my very first firewall rule on WAN to allow IPV6 proto any from any.

Not sure how to scale this screenshot for the forum, so have attached the jpg below, too:


Again I can now ping OPNsense but NOT connect ssh or https over IPv6.

As a final measure to see if this is perhaps an upstream issue of sorts I ssh in (via IPv4) and do pfctl -d

At that point IPv6 connections are accepted. I can SSH / https to the box over IPv6! How ? Why ? Whiskey Tango Foxtrot?

Attached a sanitized packet capture where I try to ssh from 2604:aa10:9211:2:68c2:f15e:579d:af88 to the WAN address. It shows the pass rule on WAN is working but then things break when OPNsense is trying to reply.

Gateway status shows up, OPNsense can initiate IPv6 conversations successfully. I do not get it.