professional-service-best-practices/professional-service

Fork 0

OPNsense Mgmt Interface: Public WebUI Access Not Working #52

New issue

Closed

opened 2026-07-23 12:44:39 +00:00 by sven.schmidt · 4 comments

sven.schmidt commented

2026-07-23 12:44:39 +00:00

Owner

@sven.schmidt as discussed. The following issues needs to be addressed as well:

(docs) Documentation about setting up the Mgmt Interface
(fix) Currently there is no known way to pass Mgmt Access via Public IP to WebUI. (Public Client IP -> Public IP Mgmt NIC -> Mgmt IP) Outbound it routes via Default Route (WAN) -> No Connection possible
- Temp fix: Set default route to Mgmt GW and navigate through WebUI
- Tested several rule sets (e.g. rules[new] and rules) including setting a rule for 443 with Gateway or reply-to -> Both not working
- Tested priority changes of gateways -> not working

Originally posted by @marc.adrian in #51 (comment)

@sven.schmidt as discussed. The following issues needs to be addressed as well: - (docs) Documentation about setting up the Mgmt Interface - (fix) Currently there is no known way to pass Mgmt Access via Public IP to WebUI. (Public Client IP -> Public IP Mgmt NIC -> Mgmt IP) Outbound it routes via Default Route (WAN) -> No Connection possible - Temp fix: Set default route to Mgmt GW and navigate through WebUI - Tested several rule sets (e.g. rules[new] and rules) including setting a rule for 443 with Gateway or reply-to -> Both not working - Tested priority changes of gateways -> not working _Originally posted by @marc.adrian in https://professional-service.git.onstackit.cloud/professional-service-best-practices/professional-service/issues/51#issuecomment-699_

sven.schmidt commented

2026-07-23 12:48:18 +00:00

Author

Owner

@marc.adrian

An additional Security Group should not be required for the firewall itself, as this would contradict the purpose of using a firewall as the central component for traffic filtering and rule enforcement.

However, if a specific use case or customer requirement requires source IP restrictions at the infrastructure level, the allowed addresses must be maintained directly on the NIC via the API:

Update Network Interface – STACKIT API Documentation

This introduces additional management overhead, but it is necessary if this setup is intended to be operated with infrastructure-level IP restrictions.

@marc.adrian An additional Security Group should not be required for the firewall itself, as this would contradict the purpose of using a firewall as the central component for traffic filtering and rule enforcement. However, if a specific use case or customer requirement requires source IP restrictions at the infrastructure level, the allowed addresses must be maintained directly on the NIC via the API: [Update Network Interface – STACKIT API Documentation](https://docs.api.stackit.cloud/documentation/iaas/version/v2#tag/Network-Interface/operation/V2UpdateNIC) This introduces additional management overhead, but it is necessary if this setup is intended to be operated with infrastructure-level IP restrictions.

sven.schmidt closed this issue

2026-07-23 12:48:18 +00:00

sven.schmidt commented

2026-07-23 13:57:59 +00:00

Author

Owner

Reopening this issue to summarize the root cause:

In this case, the HTTPS traffic flow was asymmetric:

MGMT ingress → WAN egress

The request to the WebUI arrived through the MGMT interface, but the response traffic was sent through the default route via WAN. Therefore, an explicit setting was required to ensure that the return traffic used the corresponding MGMT gateway.

Please check the OPNsense floating rules. There may already be a rule for TCP/443 that matches the WebUI traffic before the dedicated MGMT interface rules are evaluated.

Possible solutions:

Configure an explicit reply-to on the matching floating rule and point it to the corresponding MGMT gateway.
Remove the floating TCP/443 rule and handle the traffic exclusively through the dedicated MGMT interface rules.
Add a TCP/443 allow rule on the MGMT interface for WebUI access and ensure that the correct MGMT gateway is used for the return traffic.

Reopening this issue to summarize the root cause: In this case, the HTTPS traffic flow was asymmetric: `MGMT ingress → WAN egress` The request to the WebUI arrived through the MGMT interface, but the response traffic was sent through the default route via WAN. Therefore, an explicit setting was required to ensure that the return traffic used the corresponding MGMT gateway. Please check the OPNsense floating rules. There may already be a rule for TCP/443 that matches the WebUI traffic before the dedicated MGMT interface rules are evaluated. Possible solutions: * Configure an explicit `reply-to` on the matching floating rule and point it to the corresponding MGMT gateway. * Remove the floating TCP/443 rule and handle the traffic exclusively through the dedicated MGMT interface rules. * Add a TCP/443 allow rule on the MGMT interface for WebUI access and ensure that the correct MGMT gateway is used for the return traffic.

👍 1

sven.schmidt reopened this issue

2026-07-23 13:58:00 +00:00

sven.schmidt commented

2026-07-23 13:58:51 +00:00

Author

Owner

@marc.adrian please recheck if this solves the initial Issue

sven.schmidt self-assigned this

2026-07-23 13:59:54 +00:00

sven.schmidt removed their assignment

2026-07-23 13:59:59 +00:00

sven.schmidt self-assigned this

2026-07-23 14:00:04 +00:00

marc.adrian commented

2026-07-24 13:15:44 +00:00

Owner

@sven.schmidt yes, this solves the issue - this might be documented in README when rework on #51

@sven.schmidt yes, this solves the issue - this might be documented in README when rework on [#51](https://professional-service.git.onstackit.cloud/professional-service-best-practices/professional-service/issues/51)

👍 1

marc.adrian closed this issue

2026-07-24 13:16:14 +00:00

sven.schmidt referenced this issue

2026-07-27 10:47:20 +00:00

Rework Hub & Spoke Example #51

sven.schmidt referenced this issue

2026-08-04 06:33:47 +00:00

Rework Hub & Spoke Example #51