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 - phaze75

#1
Quote from: Bob.Dig on March 10, 2025, 06:21:02 PMMaybe they are guarded by their hosts-firewalls?

Thanks for the suggestion, but no. The firewall rules are not the issue.

ChatGPT pointed me to the solution:

Adjust WireGuard Peer Configurations

On each WireGuard client (peer), check the AllowedIPs setting:
Change AllowedIPs = 0.0.0.0/0 (or similar) to include the LAN network:

     AllowedIPs = 192.168.0.0/24, 0.0.0.0/0

This ensures that traffic destined for 192.168.0.0/24 is sent through the VPN tunnel.
Restart the WireGuard client after making the changes.

Adding 192.168.0.0/24 to AllowedIPs did the trick.
#2
Dear all,

Coming from a years-old OpenVPN setup, I just have configured WireGuard. I followed the "WireGuard Road Warrior Setup" installation guide and successfully completed the setup. I have one instance and two peers connecting flawlessly from LAN and WAN, including the firewall rule for peers to access the Internet.

However, there is still one task open. My WireGuard service uses the private network 192.168.1.0/24 and my LAN uses the private network 192.168.0.0/24. While the WireGuard peers can access the Internet, they cannot access any of my LAN services. I tried several firewall rules with the LAN and WireGuard interfaces, but no success so far. I had a similar setup with OpenVPN working, using two separate private networks.

I know the solution must be rather trivial, but I simply don't get to it. Could you please help me out?
#3
Quote from: franco on December 06, 2024, 01:23:26 PM
I was under the impression this was merged, but apparently not. We'll get that done for 24.7.11.


Cheers,
Franco

That is great news! Thanks!
#5
Hi,

I would like to revive/reopen this feature request initially discussed here and opened on Github in 2018. The feature request currently seems to have the status "closed", based on some restraints of nut and opnsense's dashboard back then. Some water ran down the river since and with 24.7 a new dashboard technology has been deployed. Maybe, this offers a chance for reconsideration?

https://forum.opnsense.org/index.php?topic=9459.msg42956#msg42956

https://github.com/opnsense/plugins/issues/803
#6
Quote from: bman on October 25, 2024, 03:57:24 PM
Postfix is a server and can send emails to other servers. I have never seen Postfix to behave as client and authenticate itself as client - MSA. But mybe it is doable with some specific steps.

For every trusted connection between MTAs it is necessary to establish trust. One way or the other. The simplest way is to configure a trusted relay with a fixed IP. But there are other options.

Quote from: bman on October 25, 2024, 03:57:24 PM
So use SMTP "AUTH" - and very often plain -simple user/password.
Now MS will remove it and will use OATH authentication.

So no, MS does not remove SMTP AUTH, just changes the auth method and client has to support it.

Indeed, I could have been more succinct. Microsoft is merely altering the authentication method. However, given that most clients, including Monit, lack OAuth2 support, it's unlikely they will adapt by September 2025, if at all.
#7
True that.

Sending email to MS365 would be sufficient. But you are right, as there is no trust or authentication established, every email sent will be fully affected by MS365's anti-spam policies. So there will always be a risk of alerts not going through. Not very favorable.

I just checked specifically for OAuth2 support by postfix and sendmail. Nothing. Well, OAuth2 is not part of the SMTP protocol standard (yet). The topic seems to be lingering for quite some time, as I found many posts - some of them years old. Google/Gmail seems to be on the same page.

The question is how this requirement will be handled in the near future. I guess many will be affected next year as soon as MS365 will not support SMTP AUTH anymore, as not everybody runs on fixed IPs. Especially not small businesses.

There is a quite nice and comprehensive OAuth2 CLI to fetch tokens: https://github.com/cloudentity/oauth2c
#8
Giving postfix on opnsense a second thought: why would I need a fixed IP? If I run postfix as a purely internal (LAN) smtp relay for my remaining on-premise services (e.g. monit), it wouldn't even need to be published on the WAN, would it? As long as smtp-mail.outlook.com would then accept all emails relayed by opnsense/postfix.

Or do I miss something here?
#9
Thanks for the advice, but unfortunately I don't have a fixed public IP address (anymore). I recently moved most of my on-premise services into the cloud(s). Thus, I only maintain a small office network running on opnsense with a dynamic IP. And I use monit to monitor those cloud services.
#10
Hi there,

recently Microsoft disabled basic username/password authentication (SMTP AUTH) for smtp-mail.outlook.com: https://tinyurl.com/ypf5w7s5

My company is using Microsoft 365 cloud services and I only realized that because Monit "stopped" sending alert emails. For now I could manually override the disabling, but it would only buy me a year, as MS will remove SMTP AUTH support by September 2025. See link above.

Thus my question: is opnsense/monit able to authenticate via OAuth2? The current configuration webform does not offer this option. My research did not come up with any hints towards OAuth2 support.

Thanks in advance for your support!
#11
General Discussion / RRD stats for Monit services?
August 19, 2024, 06:50:51 PM
Hello,

I would like to track several Monit remote host services (https, etc.) that I monitor against a timeline to visualize e.g. their response times and their down times.

I get the alerts reliably into my Inbox, but I need to "manually" process each email and compile a table to create a summary/visualization of the service availability/quality. So, it would be great to automatize that. OPNsense has a great RRD based reporting engine, so I was wondering if it was possible to connect Monit to it. Please advise!

Thanks, and best regards!
#12
Worked for me too. Thanks.
#13
Well, I understand that those records are steered/fed by the DHCP service. But still, the DHCP service is the sending end, and the DNS service is the receiving end (as DNS is not directly serving DHCP's config files). In order to check or troubleshoot I would like to be able to see what is actually served to the network by the respective service. On the DHCP side it is clear and viewable, on the DNS side it is not. Further, I would like to see the record types (A, AAAA, CNAME, etc.) and if the FQDNs are correct. So, imho checking a DNS zone is not an uncommon use case.

Best regards!