which won´t need additional *.pem files in /certs are not a good solution since the information button for N2N clients is then useless.
The bash snipped or something with the same affect from above might be something for update.sh and all already existing N2N client connections but changes needs to be done in ovpnmain.cgi for every new N2N client import may somewhere around here ?
I would expect that it will apply in either case. It is only a flagging of the status. It doesn’t change anything in the certificate.
My understanding from @ummeegge in an earlier post is that the code is looking for .pem files but the N2N only uses .p12 files and the check process for the date in the certificate is probably getting an error message which is being translated as that the certificate has expired. (I have not looked through the code so this is a presumption on my behalf).
@tphz
I am glad you found and reported this bug. I am following the topic.
We did well to hope for help from other users.
I thank you for encouraging me in the previous post to help you.
Although I figured out how to configure n2n in IPFire, I couldn’t help you in any way because I don’t have “another n2n server to hook into,” so I can’t do any testing.
Unity is strength. This is the strength of the IPFire community!!!
I try to describe a scenario, just encountered for CU173 stable. I do not know if it is normal and I do not know if it also occurs for CU174 test.
I set up 2 rules in the firewall:
The first one performs a port forward to local port 68nn for external IP 176.n.n.n avoiding creating the LOG.
The second performs a port forward to local port 68nn for all Italian external IPs, creating the LOG.
Despite these 2 rules, it seems from the LOGs that there are (from time to time) DROP_INPUT conditions for IP 176.n.n.n
Is this normal?
The firewall rules shown have a destination of 172.16.3.1 while the drop log message is for a destination of 192.168.111 4 and therefore does not match your rules. So the drop message is normal.
You are absolutely right. I got confused with the RED, since my router forwards to 192.168… In fact, I tried disabling the first rule. all OK!!! I thank you and apologize for not checking properly before .
It would appear that some packets (which the router forwards to 192.168.111.4) are not being forwarded over to orange. Since this is a condition that does not comply with the rules I have set, it logically gets blocked .
.
someone is needed to report a bug !
.