I currently host an obfs4-bridge over my DD-WRT router with no issues. I would like to continue to host my obfs4-bridge, but with WireGuard enabled as an attempt to better protect my networks everyday web traffic in addition to contributing to the Tor network.
the WireGuard connection is confirmed to be established with no issues.
here are the adjustments that I have made as I prepare to run my obfs4-bridge over this WireGuard connection:
changed the Address <IP> of the /etc/tor/torrc of my obfs4-bridge hosting device from my public IP [prior to enabling WireGuard] (according to nslookup myip.opendns.com resolver1.opendns.com) to my new public IP [after enabling WireGuard] (according to nslookup myip.opendns.com resolver1.opendns.com). note: this new public IP is different than the “Endpoint Address” listed in my WireGuard settings (D-WRT > Setup > Tunnels).
I added a firewall rule on my obfs4-bridge hosting device to allow the WireGuard “Listen Port” (provided in the WireGuard settings (D-WRT > Services > Tunnels)).
following these adjustments and sudo systemctl restart tor, my obfs4-bridge TCP port is still not reachable when testing with The Tor Project TCP Reachability Test - here is the error message given: TCP port is *not* reachable! Here’s the error message we are getting: dial tcp <WAN IP>:<obfs4 bridge port> i/o timeout
I suspect that I need to do some DD-WRT port forwarding?
did I make the right choice by changing the Address <IP> of the /etc/tor/torrc to the new public IP address [WireGuard enabled], rather than continuing to use my DD-WRT > Status > WAN > WAN IP?
I can provide the output of journalctl -eu tor@default or any other output, if needed.
I am a networking hobbyist, so the issue here may be out of my scope. also having trouble mapping out the path that the obfs4-bridge traffic travels with WireGuard enabled.
thank to anyone who is able to help me! I am open to learning/filling my networking knowledge gaps - feel free to teach me things in addition to providing potential solutions.
What kind of wireguard vpn do you use? Did you rent a vps or something similar and set it up yourself or is it just a vpn provider?
In addition could you explain why you want to do this in the first place? Im curious what benefit you hope to achieve by routing your tor bridge through a wireguard tunnel.
Hey, I am not an expert either but I can try to help you figure it out. First I was wondering if you could clarify some things…
What specifically are you trying to achieve with with WireGuard? Providing remote access to your home LAN? Hiding your router’s public IP address from bridge users?
Can you describe how your devices are connected? Is the obfs4 bridge hosted directly on the DD-WRT router, or is it running on a separate device within your network? Is your router connecting to a remote VPN server?
Can you show the output of journalctl -eu tor@default and wg show?
thanks for replaying @Tangerine! please see my reply to @jarl above - does that answer your question? also, running a VPN on my router is more convenient than having all devices on the network running their own VPN application.
the obfs4-bridge is hosted on a device this is connected via ethernet to my DD-WRT router.
the DD-WRT router is loaded with a WireGuard configuration file from my VPN provider.
here is the output of journalctl -eu tor@default with WireGuard enabled and with the Address <IP> of the /etc/tor/torrc set to the new public IP address [assigned after WireGuard enabled]. *anything inside of < > was removed before posting here:
Apr 28 17:32:11 server tor[17030]: Apr 28 17:32:11.177 [notice] Opening Extended OR listener on 127.0.0.1:0
Apr 28 17:32:11 server tor[17030]: Apr 28 17:32:11.177 [notice] Extended OR listener listening on port 39423.
Apr 28 17:32:11 server tor[17030]: Apr 28 17:32:11.177 [notice] Opened Extended OR listener connection (ready) on 127.0.0.1:39423
Apr 28 17:32:11 server Tor[17030]: We compiled with OpenSSL 300000a0: OpenSSL 3.0.10 1 Aug 2023 and we are running with OpenSSL 300000a0: 3.0.10. These two versions should be binary compati>
Apr 28 17:32:11 server Tor[17030]: Tor 0.4.8.11 running on Linux with Libevent 2.1.12-stable, OpenSSL 3.0.10, Zlib 1.2.13, Liblzma 5.4.1, Libzstd 1.5.5 and Glibc 2.38 as libc.
Apr 28 17:32:11 server Tor[17030]: Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/staying-anonymous/
Apr 28 17:32:11 server Tor[17030]: Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Apr 28 17:32:11 server Tor[17030]: Read configuration file "/etc/tor/torrc".
Apr 28 17:32:11 server Tor[17030]: Based on detected system memory, MaxMemInQueues is set to 630 MB. You can override this by setting MaxMemInQueues by hand.
Apr 28 17:32:11 server Tor[17030]: Opening Socks listener on 127.0.0.1:9050
Apr 28 17:32:11 server Tor[17030]: Opened Socks listener connection (ready) on 127.0.0.1:9050
Apr 28 17:32:11 server Tor[17030]: Opening OR listener on 0.0.0.0:8675
Apr 28 17:32:11 server Tor[17030]: Opened OR listener connection (ready) on 0.0.0.0:8675
Apr 28 17:32:11 server Tor[17030]: Opening Extended OR listener on 127.0.0.1:0
Apr 28 17:32:11 server Tor[17030]: Extended OR listener listening on port 39423.
Apr 28 17:32:11 server Tor[17030]: Opened Extended OR listener connection (ready) on 127.0.0.1:39423
Apr 28 17:32:18 server Tor[17030]: Your Tor server's identity key fingerprint is <private>
Apr 28 17:32:18 server Tor[17030]: Your Tor bridge's hashed identity key fingerprint is <private>
Apr 28 17:32:18 server Tor[17030]: Your Tor server's identity key ed25519 fingerprint is <private>
Apr 28 17:32:18 server Tor[17030]: You can check the status of your bridge relay at <private>
Apr 28 17:32:18 server Tor[17030]: Configured hibernation. This interval began at 2024-04-28 01:00:00; the scheduled wake-up time was 2024-04-28 01:00:00; we expect to exhaust our quota fo>
Apr 28 17:32:18 server Tor[17030]: Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Apr 28 17:32:19 server Tor[17030]: Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Apr 28 17:32:20 server Tor[17030]: Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.
Apr 28 17:32:20 server Tor[17030]: Bootstrapped 0% (starting): Starting
Apr 28 17:32:26 server Tor[17030]: Starting with guard context "default"
Apr 28 17:33:14 server Tor[17030]: Signaled readiness to systemd
Apr 28 17:33:14 server systemd[1]: Started tor@default.service - Anonymizing overlay network for TCP.
Apr 28 17:33:14 server Tor[17030]: Registered server transport 'obfs4' at '[::]:1443'
Apr 28 17:33:15 server Tor[17030]: Bootstrapped 5% (conn): Connecting to a relay
Apr 28 17:33:15 server Tor[17030]: Opening Socks listener on /run/tor/socks
Apr 28 17:33:15 server Tor[17030]: Opened Socks listener connection (ready) on /run/tor/socks
Apr 28 17:33:15 server Tor[17030]: Opening Control listener on /run/tor/control
Apr 28 17:33:15 server Tor[17030]: Opened Control listener connection (ready) on /run/tor/control
Apr 28 17:33:15 server Tor[17030]: Not advertising Directory Service support (Reason: AccountingMax enabled)
Apr 28 17:33:15 server Tor[17030]: Bootstrapped 10% (conn_done): Connected to a relay
Apr 28 17:33:16 server Tor[17030]: Bootstrapped 14% (handshake): Handshaking with a relay
Apr 28 17:33:16 server Tor[17030]: Bootstrapped 15% (handshake_done): Handshake with a relay done
Apr 28 17:33:16 server Tor[17030]: Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
Apr 28 17:33:16 server Tor[17030]: Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
Apr 28 17:33:16 server Tor[17030]: Bootstrapped 95% (circuit_create): Establishing a Tor circuit
Apr 28 17:33:17 server Tor[17030]: Bootstrapped 100% (done): Done
Apr 28 17:33:17 server Tor[17030]: Now checking whether IPv4 ORPort <public IP w/ WireGuard enabled>:8675 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Apr 28 17:33:26 server Tor[17030]: Your network connection speed appears to have changed. Resetting timeout to 60000ms after 18 timeouts and 1000 buildtimes.
Apr 28 17:53:15 server Tor[17030]: Your server has not managed to confirm reachability for its ORPort(s) at <public IP w/ WireGuard enabled>:8675. Relays do not publish descriptors until their ORPort and Dir>
lines 956-1000/1000 (END)
=
here is the output of wg show on my DD-WRT router. *anything inside of < > was removed before posting here:
interface: oet1
public key: <public key>
private key: (hidden)
listening port: <listening port>
peer: <peer>
endpoint: <endpoint IP address>:<listening port>
allowed ips: 0.0.0.0/0
latest handshake: 1 minute, 53 seconds ago
transfer: 617.88 MiB received, 9.58 MiB sent
persistent keepalive: every 26 seconds
thanks for replying! I downloaded a WireGuard configuration file from my VPN provider and imported the configuration file to my router, which is flashed with DD-WRT.
regardless of hosting a obfs4-bridge, the primary reason for enabling a [WireGuard] VPN on my router is improve the privacy and security of my network traffic. aside from this, hosting my obfs4-bridge through a [WireGuard] VPN just feels like good hygiene.
The address you use in your torrc has to be reachable from the internet for your bridge to work. If you use the ip you get from your vpn-provider people try to reach you over this ip, but your provider almost certainly won’t forward this traffic to you. I don’t know if there are porviders who support port forwarding, but most don’t.
If you really want to use your vpn for outgoing connections you could play around with some firewall rules on your openwrt and the OutboundBindAddress option in your torrc and make it work, but i don’t see any benefit there.
@jarl@Tangerine one thing that may be worth noting is that, after I enable WireGuard on my DD-WRT router, I can still ping my WAN IP (the IP that I typically host my obfs4-bridge) (avg time=1.082ms) and I can also ping my new public IP address (assigned with WireGuard enabled) (avg. time=34.246ms).
I have a feeling that I should continue to use my WAN IP as the Address <IP> of the /etc/tor/torrc of my obfs4-bridge and then set up some type of port forwarding for WireGuard?
I should be able to send whatever outgoing traffic (obfs4-bridge traffic or not) to my VPN provider prior to continuing on to its destination, is that right?
as for incoming [obfs4-bridfe] traffic back to my network, I feel like I know what @jarl means by if I use the WireGuard provided public IP in my /etc/tor/torrc then my the VPN provider probably is not willing/able to forward obfs4-bridge traffic back to my network… which is why I am thinking that part of the solution is to continue to use my WAN IP in my /etc/tor/torrc. thanks for helping me mull this over
If you get incoming traffic for your bridge over the WAN ip you don’t need any port forwarding for your wiregurad connection. Port forwarding ist generally only needed if you want to get connections to your network which aren’t initiatet by you. Since those connections will address your WAN ip only the usual port forwarding in your router is required.
Just out of curiosity, could you explain why you think your bridge (and maybe your other traffic too) should use the vpn? Do you just have trust issues with your ISP or do you try to achieve something specific?