Messages

What a wonderful timing. I started working on the same problem yesterday. So far, my solution was what Amr has suggested: essentially, I have an LXD container connected to a VLAN with all traffic going through OpenVPN and with the proxy set up inside that container. Obviously, this solution works, but I also started to think about switching to simply using OPNsense with squid since it is already part of the system and to retire the container.

I figured I'd simply bind squid to the VPN subnet experienced the same issue as you minitux: the proxy ignores the VPN. I did look into squid.conf (I'm new to squid) and couldn't find anything of help. Then, I found https://forum.opnsense.org/index.php?topic=6516.0 and played with pre-auth and post-auth configs as per Amr's info about a "tcp_outgoing_address" directive. This is where I am blocked at the moment...

Let's say my VPN subnet is 192.168.x.0/24. I decided to create a file custom.conf and placed it once in pre-auth and once in the post-auth folder to test (for reference: login via shell, navigate to /usr/local/etc/squid/ where you find the folders in question). Inside my conf I specified an acl for the clients subnet (192.168.y.0/24) as well as the tcp outgoing address (gateway of VPN subnet) for these users:

Code Select Expand

acl VPNUsers src 192.168.y.0/24
tcp_outgoing_address 192.168.x.1 VPNUsers

And this is where the fun stops: with the browser configured to use the proxy, the connection times out and squid's access logs show (EDIT: NONE/503) errors.

EDIT: after some additional research I decided to give up on the OPNsense/squid combo to solve this problem. My current working solution took 3-5 minutes compared to a couple of hours of research without a working solution. Would've been cool, but not worth the hassle.

Good luck to you. And if you happen to find an answer...I'm still interested ;-)

A couple of suggestions for troubleshooting:

Remove the OPNsense box and hook up your webserver directly to your modem/router:
- If you can reach your webserver now, then it might be of some use to post your OPNsense rule configurations
- If you still can't reach your webserver, then you will want to troubleshoot another variable like:
   - Is your ISP blocking any ports? you could get in touch with them and ask about the situation regarding self-hosting
   - Is your webserver running an active firewall?

This plugin looks pretty interesting and I'd like to give you some non-technical feedback to consider. But first a question: will Sensei ever be open source?
See, the reason I ask is because to me it seems there is some confusing communication going on. I'm sure, some of it is non-intentional like:

For now I'm happy to tell that community edition for OPNsense will always be there and forever free.

"For now" and "always" don't work well together. Basically, now you're saying that this will always be the case, but later you might change your mind to "it isn't free anymore". I suspect that this was unintentional, but I just wanted to get it out of the way.

What rubs me a bit the wrong way is that the community edition is free, but not open source. According to your FAQ:

The Packet Engine coded in C++, and its source code is not open.

I think the reason there are community editions in the software space is precisely to indicate that a company/developer wants to build a trust model with others and, as a result, gives them the recipe so that they can build a community around it together. In short, it isn't about getting something for free i.e. without having to pay, but to build trust.

Now, where your approach to marketing proofs to be rather problematic is with statements like this:

Empower your open source firewall with Next Generation features.

If you plan to keep parts of Sensei closed source, I'd suggest you'd drop the "open source" in your marketing, because it's confusing at best, misleading at worst. Next, as long Sensei isn't open source, I'd also reconsider the use of "community edition": this is a rather well known way to describe the non-commercial version of a product that isn't just for the community, but also by the community. If the community doesn't have access to the code, it's not a community edition, it's a free edition.

The FLOSS community already suffers from a huge labeling problem (ever tried to explain to a non-technical user the difference between Free Software and Freeware?) so let's not muddy the waters even more.

I don't know about your business model, but for people who really care about open source it's not about getting stuff for free, it's to be able to verify the claims of company such as yours and, of course, to build a community around a solution that can be build by like-minded people without restrictions regarding code access.

Of course, at the end of the day there's always the pragmatic side to consider and there will probably be a lot of users who are perfectly fine to run proprietary software on their open source OS, but for people like me who decided to use an open source solution not because it is free of charge, but precisely because it's source code is available, Sensei won't be the solution we're looking for.

Now, with all that being said, I still appreciate your efforts.