A RUT router returns X-Frame-Options: SAMEORIGIN from its web interface, so a browser rejects embedding that interface in an iframe served from a different origin. The available evidence does not identify a supported RUTOS or VUCI setting that removes this header.
Confirm the iframe rejection
Inspect the router page response with the browser developer tools or an HTTP client. Confirm that the response containing the web interface includes the following header:
X-Frame-Options: SAMEORIGINIf the equipment interface and router interface have different origins, this policy prevents the router page from rendering inside the equipment iframe. Record the requested URL, parent-page origin, response status, and response headers before changing the architecture.
Separate RUTOS from OpenWrt LuCI guidance
The reported router interface uses VUCI rather than LuCI. VUCI is developed by Teltonika, and the available evidence describes it as closed source. Therefore, procedures written for a standard OpenWrt/LuCI web server cannot be assumed to modify the RUTOS response path.
| Approach | Evidence status | Engineering decision |
|---|---|---|
| Apply a LuCI configuration change | Reported as ineffective on RUTOS | Do not deploy without proving that the same component generates the response header. |
| Change a VUCI or RUTOS setting | No supported setting is identified | Check the applicable RUTOS SDK or official Teltonika support information before altering firmware. |
| Use a reverse proxy | Proposed architecture, not a confirmed package | Evaluate only if it can proxy the complete router interface and control the returned headers. |
Evaluate the reverse-proxy path
A reverse proxy placed between the equipment interface and router could request the router page and omit X-Frame-Options: SAMEORIGIN from the response presented to the browser. The evidence does not identify an installable RUTOS package that performs this function out of the box, so treat this as a design option rather than a documented router feature.
- Proxy a test request to the router interface without changing the router firmware.
- Inspect the browser-facing response and verify whether the blocking header is absent.
- Load the proxied page in the iframe and test login, navigation, and configuration operations required by the equipment workflow.
- Review the security impact before deployment because removing the framing restriction allows another page to present the router administration interface.
Choose the supportable implementation
Prefer a documented RUTOS configuration if Teltonika confirms one for the installed product and software release. Otherwise, keep the proxy external to the router so the change remains testable and reversible. Do not assume that modifying a LuCI file affects VUCI, and do not build a firmware modification until the applicable SDK establishes which web component emits the header.
FAQ
Why will the RUT router page not load in my iframe?
The router response contains X-Frame-Options: SAMEORIGIN. A browser blocks the page when the iframe parent is served from a different origin.
Can I use an OpenWrt LuCI fix to remove the RUTOS header?
Not without verification. The reported RUTOS interface uses VUCI, and LuCI-oriented changes were reported as ineffective.
Can a reverse proxy remove X-Frame-Options from RUTOS pages?
A proxy can be evaluated as the header-control point, but the evidence identifies no ready-made RUTOS package. Verify the browser-facing headers and every required administration operation before deployment.