1
Hardware and Performance / Re: PC Engines APU2 1Gbit traffic not achievable
« on: February 04, 2020, 09:42:13 am »
Unfortunately this is only a displaying matter.
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.
2
19.7 Legacy Series / Re: LDAPS authentication server certificate issue with Azure AD
« on: October 02, 2019, 11:22:46 am »
Okay, I found a proper workaround that would do, preferably https://github.com/opnsense/core/blob/master/src/opnsense/mvc/app/library/OPNsense/Auth/LDAP.php would do the same.
I created /root/.ldaprc with following content:
I left out the explicit TLS_CACERTFILE cause that name is somewhat dynamic and I didn't want to hardcode it.
I'll open an issue on Github to consider this as an enhancement.
I created /root/.ldaprc with following content:
Code: [Select]
TLS_REQUIRE_CERT TLS_HARD
TLS_CACERTDIR /var/run/certs
I left out the explicit TLS_CACERTFILE cause that name is somewhat dynamic and I didn't want to hardcode it.
I'll open an issue on Github to consider this as an enhancement.
3
19.7 Legacy Series / Re: LDAPS authentication server certificate issue with Azure AD
« on: October 02, 2019, 11:08:47 am »
It might be an upstream problem in PHP:
https://bugs.php.net/bug.php?id=73558
Question: Can there be any workaround, e.g. not using LDAP_OPT_X_TLS_CACERTFILE as it is anyway not working as intended? Putting the configured certificates into the global trust store might work.
https://bugs.php.net/bug.php?id=73558
Question: Can there be any workaround, e.g. not using LDAP_OPT_X_TLS_CACERTFILE as it is anyway not working as intended? Putting the configured certificates into the global trust store might work.
4
19.7 Legacy Series / LDAPS authentication server certificate issue with Azure AD
« on: October 01, 2019, 03:23:01 pm »
Hello,
I am trying to add an LDAPS server to the list of authentication options in "System > Access > Servers". More precicely, it is the LDAPS server of Microsoft Azure AD (https://docs.microsoft.com/en-us/azure/active-directory-domain-services/tutorial-configure-ldaps).
This is working absolutely fine on a pfSense machine, users can authenticate in OpenVPN easily.
However, adding the server in OPNsense is a bit of a hassle. When testing the server, this is what the logfile says:
The certificate is a self-signed one, created by an internal Sub CA (it was done on the pfSense machine, same way you can do it on OPNsense). However, it seems OPNsense is unable to verify the trust chain for the server certificate while pfSense is.
I installed the entire trust chain into the OPNsense trust store so in general the certificates are there. It just seems that they are not being used.
Can someone help me to find out more and identify the root cause? I am running on latest version 19.7.4_1.
Thanks,
Julian
I am trying to add an LDAPS server to the list of authentication options in "System > Access > Servers". More precicely, it is the LDAPS server of Microsoft Azure AD (https://docs.microsoft.com/en-us/azure/active-directory-domain-services/tutorial-configure-ldaps).
This is working absolutely fine on a pfSense machine, users can authenticate in OpenVPN easily.
However, adding the server in OPNsense is a bit of a hassle. When testing the server, this is what the logfile says:
Code: [Select]
opnsense: LDAP bind error [error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (unable to get issuer certificate),Can't contact LDAP server]The certificate is a self-signed one, created by an internal Sub CA (it was done on the pfSense machine, same way you can do it on OPNsense). However, it seems OPNsense is unable to verify the trust chain for the server certificate while pfSense is.
I installed the entire trust chain into the OPNsense trust store so in general the certificates are there. It just seems that they are not being used.
Can someone help me to find out more and identify the root cause? I am running on latest version 19.7.4_1.
Thanks,
Julian
5
19.1 Legacy Series / Re: Wireguard - multiple endpoints not in wg0.conf
« on: September 01, 2019, 01:17:26 pm »
---
6
19.1 Legacy Series / Re: pkg.opnsense.org not reachable via IPv6
« on: April 13, 2019, 10:04:36 am »
I can confirm it is working again, potentially a peering issue of Vodafone I guess.
7
19.1 Legacy Series / Re: pkg.opnsense.org not reachable via IPv6
« on: April 11, 2019, 04:22:50 pm »
Yep, it is working just fine for everything else.
Just changed the screenshot to prove connectivity to another IPv6 website is working .......
Just changed the screenshot to prove connectivity to another IPv6 website is working .......
8
19.1 Legacy Series / [RESOLVED] pkg.opnsense.org not reachable via IPv6
« on: April 11, 2019, 04:16:31 pm »
Hi,
it is currently not possible to do any updates using IPv6 connectivity.
It seems pkg.opnsense.org is not responding on it's v6 address, connecting to v4 works fine.
Can somebody look into this please?
-Julian
it is currently not possible to do any updates using IPv6 connectivity.
It seems pkg.opnsense.org is not responding on it's v6 address, connecting to v4 works fine.
Can somebody look into this please?
-Julian
9
18.7 Legacy Series / Re: IPv6 default route lost / ICMP6 RA not received
« on: February 09, 2019, 12:30:26 pm »
Just wanted to let you know, after upgrading to 19.1.1 everything seems to work. Keep your fingers crossed! :-D
10
Hardware and Performance / Re: APU2 Bios
« on: February 08, 2019, 03:34:46 pm »
No issues as far as i can tell
12
Hardware and Performance / Re: APU2 Bios
« on: January 22, 2019, 09:47:01 am »
awww, people report the reboot issue to be finally fixed for the mainline version.
Sounds promising, might be worth giving it a try. but maybe not mixing it up together with 19.1 migration - just to make sure there is nothing interfering, you never know...
Sounds promising, might be worth giving it a try. but maybe not mixing it up together with 19.1 migration - just to make sure there is nothing interfering, you never know...
13
18.7 Legacy Series / Re: Unbound not listening on IPV6 address
« on: January 06, 2019, 06:01:51 pm »
In my opinion, this still sounds like a bug.
"Prefer IPv4 over IPv6" should not mean the daemon shall not listen on IPv6 at all. What I'd expect is that whenever outbound connections are made, IPv4 is preferred. It might be that this is not possible to do properly with Unbound but then a dedicated setting in Unbound should be there for it and the central setting should not be taken into account.
Might be worth opening a ticket for it on Github, but that's up to you guys.
"Prefer IPv4 over IPv6" should not mean the daemon shall not listen on IPv6 at all. What I'd expect is that whenever outbound connections are made, IPv4 is preferred. It might be that this is not possible to do properly with Unbound but then a dedicated setting in Unbound should be there for it and the central setting should not be taken into account.
Might be worth opening a ticket for it on Github, but that's up to you guys.
14
18.7 Legacy Series / Re: IPv6 default route lost / ICMP6 RA not received
« on: January 06, 2019, 05:57:23 pm »
Can somebody help to guide me how to debug this any further, please?
15
18.7 Legacy Series / Re: IPv6 default route lost / ICMP6 RA not received
« on: January 02, 2019, 02:54:10 pm »
After rebooting the device, the issue is back.
What I noticed is that the connection would be stable as long as a client would ping to the internet. As I was stopping the ping from that client, die v6 default route on the FW would immediately disappear.
I deleted all VIPs on all interfaces and rebooted the device. Shortly after I am still facing the same issue...
I can see that igb0 still has the public IP assigned but the default route is missing.
Looking into the DHCP log "Services > DHCPv4 > Log file" and filter for "dhcp6c" shows that RENEW replies are being received and the address added to the interface. However, I don't think it is an DHCP issue because the interface does have it's public IP but the routing table does not have that default route set.
What I noticed is that the connection would be stable as long as a client would ping to the internet. As I was stopping the ping from that client, die v6 default route on the FW would immediately disappear.
I deleted all VIPs on all interfaces and rebooted the device. Shortly after I am still facing the same issue...
I can see that igb0 still has the public IP assigned but the default route is missing.
Looking into the DHCP log "Services > DHCPv4 > Log file" and filter for "dhcp6c" shows that RENEW replies are being received and the address added to the interface. However, I don't think it is an DHCP issue because the interface does have it's public IP but the routing table does not have that default route set.