After upgrading to RUTC_R_00.07.11, IPsec connections no longer work. The error points to a constraint check failure. What needs to be done to fix this? Were there any changelog warnings about compatibility issues between firmware versions?
Log:
3845 Sat Nov 30 17:15:42 2024 daemon.info ipsec: 11[IKE] <HQ|1> authentication of ‘mikrotik.hq.acme’ with RSA signature successful
3846 Sat Nov 30 17:15:42 2024 daemon.info ipsec: 11[CFG] <HQ|1> constraint check failed: identity ‘O=HQ.ACME, CN=mikrotik.hq.acme’ (ID_DER_ASN1_DN) required, not matched by ‘mikrotik.hq.acme’ (ID_FQDN)
I wanted to share a solution I found for this Tamagochi-like product:
To resolve the problem, you need to manually include the value from the “Remote identifier” field in the GUI into the configuration file /var/swanctl/swanctl.conf under (connections.NAME.remote.id) (IPsec connection must be already enabled in GUI). After that, running swanctl --load-conns will allow it to work until the next modem restart.
While this workaround is effective, I would like to suggest an improvement: enabling more direct configuration of the product without relying heavily on the GUI. Allowing users to configure settings directly without additional steps like this could improve the overall experience.
The hardware is impressive, but I believe the software could benefit from a more robust SDLC approach or further refinement. In particular, I think adopting a professional SDLC could help eliminate some of the drawbacks in the product’s architecture, making it more reliable and user-friendly.
I feel like a beta tester too!
The changelog says “IPsec: migrated to swanctl”. What ever it was before that was more stable. My encryption proposals no longer worked. No error, no logs in the Web-GUI. After digging around on the shell I got the hint: “loading connection ‘VPN’ failed: invalid value for: proposals, config discarded”
A regression, thanks. Why still have “AES256 GCM16” in the Web-GUI then, if it breaks the daemon?
Second regression: It can’t start at boot up…
daemon.info ipsec: 10[IKE] <VPN|1> unable to resolve vpn.example.com, initiate aborted
…of course you have to wait until online! No retry, no nothing.
You are right. I must admit that I initially assumed the high price was not for the hardware alone but for a professional-grade solution, particularly given its designation as industrial-grade equipment. However, I have uncovered numerous fundamental bugs that undermine this expectation. For example:
The inability to run multiple DHCP servers on independent interfaces, despite the GUI allowing it.
Wi-Fi RADIUS connectivity failing when a tunnel to the target is reestablished.
Multiple IPsec issues.
Certain fields in the GUI not being propagated correctly to core configuration files.
Incorrect sequencing of service startups and poor handling of their dependencies, which can significantly affect security and stability.
etc.
It puzzles me why Teltonika invests in developing such a subpar GUI instead of offering a straightforward, Linux-like image. Industry professionals could easily adapt and configure such a solution, ensuring robustness and flexibility. The current GUI-centric approach may suffice for basic use cases, such as on trucks or buses, where less experienced users reset the device frequently (without much concern) and rely on simple configurations. However, it falls short for scenarios demanding a robust, secure, and reliable solution.
I cannot recommend Teltonika for deployments where high reliability and security are paramount. When GUI fields are ignored or propagated incorrectly to configuration files, it raises serious doubts about the accuracy and security of critical settings, such as those related to routing, VLANs, and firewall rules. A poorly implemented GUI compromises trust in the entire solution. Regrettably, the quality of the GUI here is among the worst I have encountered in devices priced above $300 (and even above $50).
Thank you for reaching out.
I’d like to investigate the issues you’re experiencing further. For the initial issue with IPsec identity a troubleshoot file would be useful for issue identification.
I have sent you a form to fill our to reach out to us privately. When filling out the form, please use 10772 as the ticket ID. This is needed, as the troubleshoot file contains sensitive information.
Thank you for the help!
@Daumantas, there is no need to communicate further on this matter unless you wish to address the other issues mentioned above. The IPsec identity issue can be resolved by using the “Remote Identifier” that is already available in the GUI under IPsec/General Settings. I’ve already outlined where this value should be propagated in my previous message.
You have all the details you need - please let me know if anything else is unclear.
We’re sorry to hear about your experience with the RUTC50 device and the issues you’ve encountered.
While troubleshooting the issues you mentioned more in-depth would require additional information (logs, configuration files), there are a few points I’d like to address:
Running DHCP server on independant interfaces
It’s possible to create separate VLANs for seperate interfaces, and as long as a logical static interface is configured, DHCPv4 and v6 servers can be enabled on both logical interfaces at once. Perhaps I misunderstood the issue?
Multiple IPsec issues
The issue you described initially is already being investigated by our RnD team. Could you describe the other issues you’ve found?
Certain fields in the GUI not being propagated correctly to core configuration files.
Would you mind providing a list of the affected fields and the configuration menus that they are in?
I’d like to relay as much of this information to our RnD as possible to help mitigate these issues. Thank you for your cooperation and help!
Regarding the DHCPD: it is described in detail at this link. The issue is that your so-called solution cannot listen on two independent interfaces, nor can it run two separate daemons to handle these interfaces independently. This presents a significant security risk, as it requires trusting that you can effectively separate the two zones virtually. Based on my observations while working with your product, I do not have confidence that your company can ensure this separation.
In addition, your GUI allows users to configure two separate DHCPD for two independent interfaces, but only one configuration is actually applied (sic!) the second is ignored entirely, leaving users unaware of the problem. This is a fundamental issue, and I am genuinely shocked that it has been ignored for more than two months. Frankly, this gives me serious doubts about your QA&QC processes. The fact that such an obvious flaw has not been addressed suggests a lack of proper testing and attention to detail.
It is especially frustrating when companies like Cisco and even MikroTik clearly understand the importance of these configurations and offer solutions that support them. It’s difficult to trust that your company is taking security and quality seriously when such basic issues are left unresolved.
ad Multiple IPsec issues: One issue I remember (before version 7.11) was the inability to establish multiple data SAs with a single peer. The peer would accept the proposal, but the Teltonika device couldn’t apply its own proposal. I didn’t investigate this further because there were other issues I don’t quite remember, and I’ll try to explain why:
In the past, I attempted to raise the DHCPD issue, but the response was unhelpful, and the forum was flooded with spam, so I decided not to pursue it further. Since then, I’ve been using the device at home with a simple configuration. It’s not really enterprise-capable, which is why I’m using it in a minimal setup instead of for professional or enterprise use. I’ve been managing with a single SA and ignoring the other issues.
However, the latest firmware upgrade broke the single SA solution, rendering IPsec non-functional. As a result, I started this thread.
ad Certain fields in the GUI not being propagated correctly to core configuration files: I did not try to collect all those defects - you know - I use this device for my home/simple setup now, and while being a beta tester might be interesting, I do not see a reason to do it for free, especially after noticing how the DHCPD issue was addressed. That said, I would definitely suggest you check that all the input fields in the GUI are accurately reflected in the backend configurations and that they have the intended effect. I do believe you will find some gaps.
Regarding DHCP, I created an issue for our RnD team to investigate further.
Regarding IPsec instances, if the IPsec peer is not using Strongswan IPsec implementation, then compatibility mode usually needs to be used to establish multiple SAs. This setting can be sound under advanced connection settings:
@Daumantas, yes, if I recall correctly, we had tried that, but it had no effect. Teltonika (the initiator) was unable to correctly set up all three data channels we wanted to test, while the responder correctly assigned SPIs to them.
