Messages

that's cool. Changed that now. Should be good. Thank you!

want to run a 2-node active/passive setup in Azure. AzureLB only knows about probe results and doesn't offer a built-in active/passive LB rule by itself. Could we please have a probe mechanism (custom port maybe) that ONLY responds when the node is meant to be active - and how to realize the "backup" state when CARP obviously is not available? anyone ever built an OpnSense based IPsec in Azure using more than one node?

redeployed the nodes from scratch (again). now working. was chasing a ghost somehow...

I have connectivity between two nodes in an Azure Subnet (no NSG or other rules, route table "virtual network") and both IPs vice-versa entered for peering. I also added firewall rules on both nodes to allow access in between both. whatever I do, I always receive "The backup firewall is not accessible or not configured." under status. What's my wrong turn here? Thank you!

(I'm not talking about CARP multicast, just pfsync)

Interface names are also identical.

there is no such option in general->show_advanced

I need to run a complex BGP-based VPN with Azure (all routes learned, except for the BGP peers) and the originating opnsense has multiple NICs. FRR plugin seems randomly pick one CARP for listening. I need to specify the one being used for BGP peering listener but the webUI for FRR plugin doesn't seem to have an option for that "-l" option from FRR? how to make this work? thank you!

why don't we still not have the ability to automatically query https://endpoints.office.com/endpoints/Worldwide?ClientRequestId=<guid> and populate (predefined) FW aliases for all service areas and products, so that we easily can write a firewall rule that allows Exchange Server outbound connections to Exchange Online or Azure Core common services? that would be very helpfull, and avoids "any" rules...

such as "MicrosoftEndpoints_Exchange_993", "MicrosoftEndpoints_Skype_443", "MicrosoftEndpoints_Common_80", etc. and all these would be of type "Network" with relevant IPv4 ranges inside, obtained through the above service.

wouldn't that be great? Enterprise Players, such als PaloAlto have this for a longer time now....

I use a 1-arm proxy in a DMZ network (separate interface/vlan) that has to forward packets based on the original client IP address, so the return path (ACK) arrives opnsense but obviously it is attempted to route this "straight" to the internet and not back to the proxy, ending up in an incomplete state and retransmissions from the proxy.

I tried adding a new rule on the inside interface with matching source port / source IP criteria and custom gateway (PBR/MultiWAN-style) but the rule cannot handle the ACK portion.

Can opnsense run policy based routing based on the inbound rule only and _not_ on return paths? How to solve this differently, other than making the proxy a real routing hop in between the internet and the opnsense or in between opnsense and the target server(s)?

Thank you!

Thorsten

opnsense-patch 450ff5b5

I'd like to have the RADIUS client to parse for a configurable return attribute on grant message and its string content, maybe in delimited format, to gain group membership for RADIUS-based authentication to squid and use with along with the squid-ACL module. As of now, with RADIUS it's just a grant/deny all-in but nothing granular. ldap is not always the desired or available option. ;-)

so the new PAM logic is in place but fails with "all modules were unsuccessful for pam_sm_authenticate()". it seems it has only been checked for ldap-based authentication with respective group  configured for the proxy privilege but when using RADIUS, there is no such group import. tester shows no groups. this is a true deadlock and failure by design AFAIK.

opnsense-login also shows "user <xyz> NOT authenticated for service squid"

saved both RADIUS and PROXY but the error persists. RADIUS users do not inherit the proxy:login privilege and as the RADIUS-based authN does not provide any group memberships, the users cannot inherit from there. it's fully broken by design AFAIK.

how to apply for a fix?

the tester shows me "no groups" for my RADIUS users.

so the webproxy has changed. earlier on, any valid RADIUS user was allowed for "Proxy: Login". now they are all stalled. How to restore functionality?

it has to do with RADIUS users not inheriting the "Proxy: Login" privilege. a local user with that right works fine. How to ensure a valid RADIUS user is eligible again?