Hi
I’m new to FB and had some successes for example with installing Radicale and Featherwiki which work well. Similarly Miniflux works, but, not as I’d like. I’d prefer my selected news-sites to be anonymous to my ISP etc, by diverting all outgoing FB server traffic through Mullvad VPN.
A search of this forum led me to Configure Wireguard for Mullvad, which I followed and successfully got traffic flowing thro’ the VPN. However, I was immediately locked out of my FB whilst using the servers domain name. Fortunately, the .onion address of the box continued to work.
Can anyone suggest a solution to my problem?
My setup is as follows:
Debian Trixie 13.1
Freedombox - 25.14
RPi4 8GB RAM
A dedicated IPV4/29 address routed to FB through Opnsense firewall using Outbound NAT and FW rules on WAN & FB interfaces .
Just to clarify, when you refer to your server’s domain name, do you mean the name you have set up via the GnuDIP service https://ddns.freedombox.org? And you are using the dynamic dns client application on Freedombox?
Am I right, you can still access Freedbom box inside your LAN via freedombox.local?
Thanks for taking the time to reply.
To clarify:
I do not and have no desire, to access the FB via LAN. I have A dedicated public IPV4/29 address routed to FB through Opnsense firewall using Outbound NAT and FW rules on WAN & FB interfaces.
I use a public domain name i.e. xxxxxx.fbx.one or alternatively a .onion address to access the fb via WAN.
Hope this helps?
I have a feeling that your Wireguard app is set up to expect a peer device to communicate on an internal connection e.g., “WireGuard-Server-wg0 (wg0)”. And then that device can communicate to the outside world e.g., via WireGuard-Client-wg1 (wg1). If you look at your Network application on Freedombox, I think you’ll see that your end-user device (perhaps using wg0) only has an internal connection. At least that’s how I have my Freedombox configured.
When you verified that Wireguard was working, were you on the LAN?
I believe you can also configure the Wireguard app so that all traffic, including from an external peer, can be relayed through your FreedomBox – but I’m unclear if you can then also use Mullvad in that scenario.
This screenshot was acquired while accessing FB from .onion address.
I’m afraid my networking skills and knowledge are pretty rudimentary, hence I’ve no idea how to proceed!
@major_ludd says: “I’m afraid my networking skills and knowledge are pretty rudimentary, hence I’ve no idea how to proceed!”
I hear you. My knowledge & skills are are in a very tight neighborhood of zero. :weep:
Looking at your screenshot, I guess the configuration that you’re looking for is to connect to Freedombox (FB) via VPN. But since your Wireguard app apparently has no peers defined, I’m not sure how your end-user computer is meant to be recognized by the FB Wireguard app.
Questions: 1. Is OpnSense installed on your router or on the FB? 2. In the FB Wireguard app, do you have any peers defined that are allowed to connect to the (FB) Server? 3. Can you describe how you were initially able to confirm that the FB Wireguard app was working? 4. Is the only Wireguard configuration on your end-user machine paired with the Mullvad VPN server… and not your FB Wireguard server?
As a point of reference here’s the diagram for my FB Networks app:
You can see, in my case, my FB is connected to my router via eth0, my (internal) end-user machine connects to the Wireguard server via wg0, and then all outgoing traffic exits through wg1. And the wg0 configuration file on my end-user machine uses a key pair that is peered with the FB Wireguard app. I know this isn’t what you’re looking for, but just to define my (small) area of experience.
Mulling over what I’ve just written, I went back and looked at the configuration settings for the FB Wireguard app. It has two sections:
### As a Server
Peers allowed to connect to this server:
and
### As a Client
Servers that FreedomBox will connect to:
If I follow correctly, you’ve set up a particular Mullvad server “as a client” that Freedombox will connect to. I do wonder if you want that Mullvad server to connect to Freedombox, perhaps it has to have an entry “as a client” as well.
I don’t know if this makes sense. Just brainstorming…
First of all, I’d like to thank you yet again for your ongoing help in troubleshooting my issues.
It’s probably worthwhile taking a few sentences to reinforce my aims and objectives:
Before installing the Wireguard App I had a fully functional FBX with access to it via the WAN interface using either my domain name or an onion address.
Wishing to obfuscate from my ISP all outgoing traffic from the FBX I installed the WG app and set it up as a client connected to a Mullvad Server. That process, it seems, worked well. Except, I lost access to the box using my domain name.
I have no requirement to create a WG tunnel into the FBX via either WAN or LAN. I simply want all outgoing traffic tunneled via WG.
Moving forward, I’d like to understand and resolve why FBX is blocking my access to it when, and only when, Wireguard is enabled.
In answer to your very relevant questions:
Questions: 1. Is OpnSense installed on your router or on the FB? OpnSense is installed on dedicated Firewall device which segregates and isolates my DMZ and LAN traffic. The DMZ interface feeds several servers and devices via VLANS and managed switches. The FBX sits within the DMZ with a dedicated ipv4 address which is routed without NAT direct from the ISP.
Question 2. In the FB Wireguard app, do you have any peers defined that are allowed to connect to the (FB) Server? No
Question 3. Can you describe how you were initially able to confirm that the FB Wireguard app was working? The wireguard app has a tool showing traffic flows through it. By downloading a few unwanted apps it was clear they were going through WG
Question 4. Is the only Wireguard configuration on your end-user machine paired with the Mullvad VPN server… and not your FB Wireguard server? Yes all through Mullvad servers
Thanks for describing your configuration in more detail. That helped. I can tell I’m a bit short of understanding your use scenario. I believe you want all communication with your FBX to be anonymous but aren’t you getting this already just by using Mullvad on your end-user machine(s)?
Let’s say you don’t have Wireguard installed on FBX. Then, when you want to edit Featherwiki on FBX, you point to your end-user browser to its domain name. Because your end-user machine is connected to Mullvad, all of your queries and commits to the wiki happen inside the Mullvad tunnel. So in this case, all traffic is anonymous. What am I missing here? Maybe you have a very different use case in mind?
No, my objective is all outgoing traffic from FBX to be anonymous, I’m agnostic about incoming traffic.
Let’s say you don’t have Wireguard installed on FBX. Then, when you want to edit Featherwiki on FBX, you point to your end-user browser to its domain name. Because your end-user machine is connected to Mullvad, all of your queries and commits to the wiki happen inside the Mullvad tunnel. So in this case, all traffic is anonymous.
Respectfully disagree. With WG disabled, traffic from a client on my LAN does indeed by default pass through Mullvads servers. However, contrary to your beliefs, traffic flows between Mullvads exit server and FBX is no longer within their VPN tunnel.
The only persistent E2E tunnel occurs when using Tor’s Onion service between a client tor browser and the FBX.
I hope this helps?
@major_ludd thanks for your explanation. You’re right, it isn’t the Mullvad tunnel that protects the data from FBX back to the Mullvad server. I had that wrong. But as I think about it – in the case where Wireguard is not installed on Freedombox – wouldn’t all your Featherwiki traffic be directed from FBX to Mullvad’s server? And in transit, isn’t everything encrypted by the https protocol? So, in terms of your ISP and Featherwiki operations, if feels like both your data and your end-user machine’s IP is protected, even without FBX Wireguard. Do you think that’s right?
So maybe the issue is with Miniflux? This isn’t something I’ve used before. Is the problem that Miniflux will initiate periodic queries to news sites and you want those queries to go through Mullvad?
Question: With your current configuration, can you see if your Miniflux feed is actually getting updated? Or is the last update from before Wireguard was activated? If you are getting updates through Mullvad, then this already something quite cool.
Let’s say you are getting feed updates through Miniflux. I think the way that would work is that FBX goes out through Mullvad and then, in the context of the same session, data is returned. Then the problem is contacting the Freedombox server when you are not in the context of a Freedombox-initiated session. Maybe.
As usual, I don’t really know what I’m talking about here. Just hoping that as we stumble along, we might get somewhere. (This disclaimer should really be in my signature line… )
First the good news! With WG and Miniflux apps enabled newsfeeds traffic is flowing via onion address.
Bad News. I’m unable to use Android Client App - It will not accept an onion address unless via https. Which is impossible.
One possible explanation for the overall problem of the Wireguard App blocking both SSH and domain name access to FBX, is a firewall issue. To test this theory, and bearing in mind I have an operational Opnsense firewall, I attempted to disable the FBX firewall with command "sudo systemctl stop firewalld
" although this didn’t throw any errors in the terminal, the firewall app indicates that its still enabled. Baffled!!
So, it sounds like you have verified – with Wireguard and Miniflux enabled – that Miniflux is fetching news updates through Mullvad. Correct? Really, that is absolutely great news.
The Network diagram that you posted earlier shows that you have a network interface open for WAN. And when FBX Wireguard is disabled then you do have access. So, right, maybe something is up with the firewall.
On firewall troubleshooting:
1.) After you do sudo systemctl stop firewalld in the Freedombox CLI go to the System>Firewall page in the Freedombox GUI and use the pull-down menu to “View Logs.”
Do you see
Or is there no evidence the firewall is even trying to stop?
2.) Can you open the “web developers tools” on your end-user browser and then check the Network tab? See if you are getting individual status codes for the various GETs on the Freedombox landing page. For example are you getting a 200 for the firewall, but a 404 for everything else?
I have very little idea of how the internet actually works, so not sure if this makes sense… but here’s a scenario I am pondering.
On Freedombox with Wireguard enabled, your end-user device queries the FBX webserver via its WAN interface through HTTPS. FBX wants to respond by setting a cookie with the session ID for your browser, but its response is forced to the Mullvad server. Then, although your end-user device has not initiated any session with Mullvad, you receive the Set-Cookie response header from Mullvad. How would your end-user device know what to do with this response?
I mean, generally, I don’t feel like your end-user device would want to admit just any communication from some server on the internet… I struggle with how to express this, but your end-user device is not itself set up as a web-server… so wouldn’t most incoming requests just be blocked?
I managed to stop firewalld with “sudo systemctl mask firewalld”. However, it didn’t solve the problem. I therefore disabled the opnsense firewall. However that too failed to resolve the issue.
Time to give up with wireguard?
I really hope there is some way to salvage this approach. Even with your work so far, there are readers, who could use what you’ve done and then access their freedombox with TOR. Just so cool.
I realize this doesn’t work in your case. So, in the spirit of more brainstorming: There is this tantalizing section in the Wireguard documentation under the heading “Routing All Your Traffic.” In part, it says, that you may want to exclude some traffic from the tunnel (in your case, your end-user machine) and you can do that by munging the routing rules with specific IPs. But then under “Improved Rule-based Routing” it says:
The prior solution relies on us knowing the explicit endpoint IP that should be exempt from the tunnel, but WireGuard endpoints can roam, which means this rule may go stale. Fortunately, we are able to set an "fwmark" on all packets going out of WireGuard's UDP socket, which will then be exempt from the tunnel
By looking at my FBX-Wireguard setup (CLI command sudo wg show) I can see that FBX-Wireguard is indeed using this fwmark method. I have a feeling this is precisely so it has two different routing scenarios: one between local wireguard peers and FBX and one for the outgoing traffic to the designated Wireguard server (Mullvad in our case). That’s my guess.
So I think this dual routing scenario is baked into the FBX-Wireguard app. One routing table for end-user peers and one for the outgoing server connection.
As a test, what do you think about setting up Wireguard on your end-user device and then trying to enroll it as a peer to the FBX “server”? That is, you’d use the FBX dedicated IP address for the server endpoint in your end-user config. If that works then you might be able to take advantage of FBX-Wireguard’s apparent dual-routing configuration.
)