Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transparent Filtering Bridge: Cannot Access WebGUI on dual ethernet device if connected between modem and router #614

Open
2 tasks done
korgano opened this issue Sep 4, 2024 · 11 comments
Labels
support Community support

Comments

@korgano
Copy link

korgano commented Sep 4, 2024

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

Describe the bug

When following OPNSense guidance for transparent filtering bridge on a dual ethernet miniPC, namely Step 4 of the documented guide, the webGUI is inaccessible from any device on the network when the OPNSense device is placed in the following configuration (as recommended by tutorials):

[Modem] <==> [OPNSense transparent filtering bridge] <==> [Router]

OPNSense also cannot connect to the internet to update or install plugins.

To Reproduce

Steps to reproduce the behavior:

  1. Connect modem and router to the OPNSense host
  2. Install OPNSense on miniPC with 2 ethernet connectors.
  3. Set one ethernet jack to WAN.
  4. Set other ethernet jack to LAN.
  5. Create bridge interface with both ethernet connectors.
  6. Set a static IPv4 address and subnet mask for the bridge interface.
  7. Finish configuring the transparent filtering bridge as per guide.
  8. Attempt to connect to webGUI address.
  9. Address does not show up on router as a device and is inaccessible via other devices on network.

Expected behavior

Transparent filtering bridge is:

  1. Functional, allowing devices on network to access the internet.
  2. Visible to the router and other devices on the network.
  3. Configurable via the webGUI on any device's browser.
  4. Allowing OPNSense to update.

Describe alternatives you considered

Obtaining a USB-to-RJ45 ethernet adapter has been considered, but there seem to be issues with OPNSense recognizing such configurations as well, and generally only solves the webGUI access issue, as OPNSense cannot access the internet to update.

Additional context

This appears to be a common issue with OPNSense, with numerous Reddit and forum threads about this specific configuration or similar ones:
https://forum.opnsense.org/index.php?topic=42645.0
https://www.reddit.com/r/opnsense/comments/1c8oo2p/comment/l2ve6yl/
https://www.reddit.com/r/opnsense/comments/1f608es/transparent_filtering_bridge_issues/
https://www.reddit.com/r/opnsense/comments/1c9ic3g/access_transparent_bridge_configuration_from_lan/
https://www.reddit.com/r/opnsense/comments/1ckqyjj/reaching_gui_after_placing_opnsense_between/
https://forum.opnsense.org/index.php?topic=40032.0

@AdSchellevis AdSchellevis added the support Community support label Sep 4, 2024
@doktornotor
Copy link
Contributor

Most of the linked Reddit complaints clearly missed the Step 2, talking about some antilockout and WAN rules and similar nonsense. Hardly surprising it doesn't work.

@korgano
Copy link
Author

korgano commented Sep 30, 2024

Just want to update this issue after doing a clean install of 24.7.5 for reasons.

Issue persists, even following the OPNsense and Zenarmor guides.

WebGUI seems to only associate itself with actual physical interfaces, not the bridge or the devices own WiFi interface. There doesn't seem to be any way to alter this behavior, which makes the device completely unmanagable.

@NikGro
Copy link

NikGro commented Oct 20, 2024

@doktornotor @fichtner

Please try to take this issue more serious. Many have failed following the guide very exactly and step by step. Google searches are full of people unable to get this to work. Please try to reproduce this issue and adjust either the software or the guide. Please make sure to reproduce by exactly following the steps from the guide without adding your own knowledge into the process. I assume you will be locked out of your instance just like everyone else.

Adding the "support" tag to people's bug-reports, imagining that all of them didn't follow the guide correctly without trying to reproduce and then closing the tickets doesn't solve issues.

@fichtner
Copy link
Member

@NikGro provdie the missing steps in the docs dir and they will be added. It's very simple. Everyone can contribute.

@NikGro
Copy link

NikGro commented Oct 20, 2024

@fichtner I wish I could! I do not have the skills or knowledge to figure out the issue. Otherwise I would have provided people with the answer they are looking for. I do however have just enough talent to follow a guide, do exactly as described and, in the end, figure out that the UI is no longer accessible. All I'm hoping for is that someone of the team or someone else with the required knowledge would take the 10 minutes to set up an instance following the guide and hopefully see what's the issue causing unwanted results. As I said, i wish I could and if I could, I would love to help but it's out of my scope.

@fichtner
Copy link
Member

Technically what you are saying fits in the realm of community support. We still need to establish if there is a problem with the guide and what steps are missing or which step was misread and not followed correctly. It’s a difficult situation for all people involved. Especially after having a step by step guide provided that is supposed to deal with the actual problems and avoid it.

So are you asking to debug your setup with others?

@korgano
Copy link
Author

korgano commented Oct 20, 2024

The problem is that no one can fix the documentation, because no one actually knows what the root cause of the issue is.

As far as I know, there's no console or web GUI commands to do a diagnostic test on whether or not the web GUI is accessible through a specific interface. Without that, there's no way for anyone to provide any real data that might help debug the issue.

This is a completely opaque failure mode that points to a problem somewhere in OPNsense itself, which is beyond typical end user capability to diagnose and correct.

@fichtner
Copy link
Member

The BSD license clarifies this tremendously IMO.

@korgano
Copy link
Author

korgano commented Oct 20, 2024

What does an open source copyright license have to do with a technical issue?

Because if what you're trying to say is "Put in some code to do the diagnostics/fix the issue", you're presupposing that any of the people encountering the problem actually have the knowledge to do that.

Which I sure don't, and I don't think many/any of the people on the subreddit or forum do either.

@fichtner
Copy link
Member

Im simply unsure if you are asking for free support. I’m not here to oblige.

@fichtner fichtner transferred this issue from opnsense/core Oct 20, 2024
@NikGro
Copy link

NikGro commented Oct 21, 2024

I'm not seeking support or community help for my setup—at least not as my main goal. Of course, I’d like to get my setup working, just like anyone else posting here. However, I believe the more pressing issue is to "debug" or improve the guide itself.

As I mentioned, I’m not very knowledgeable in networking. However, I feel that the guide is well-written, leaving no unanswered questions or room to "freestyle" any of the steps. So, as far as I can tell, simply following the guide as intended shouldn’t be the issue.

Here are some observations that could make the guide even clearer, although they didn't resolve my issue:

  • Warning before Step 1: It says to apply all changes only when finished, not before. However, it doesn't mention that you need to go back to each section where changes were made and apply them individually.

  • Step 7: "Add a rule per interface"—Is this referring to an inbound or outbound rule? (I tried both options and even created two rules for each: one inbound and one outbound.)

  • Step 9: It says to set LAN and WAN interface types to "none"—does this apply to only IPv4 or also IPv6? The screenshot only shows IPv4, so I assumed it applies only to that (though I tried both).

This is where the interface lockout occurs, which makes sense since the IP I’m using to access it gets removed. However, the IP assigned to the bridge interface remains unreachable.

  • After Step 10: The guide says that only the rules on the bridge interface matter. Should the allow-all rules on LAN and WAN be removed? Or do they remain indefinitely, and I should only focus on adjusting the rules on the bridge interface?

Also some of the screenshot's and section-names are outdated. However, it remains clear, which section is meant in each step and which button's should be pressed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
support Community support
Development

No branches or pull requests

5 participants