Problem to setup Relay + bridge using a VPN for outbound connection to reach other Tor nodes

Support Relay Operator
1

Hi all,
I would like to ask for help regarding a strange configuration I’m trying to implement.

My goal is to run a Tor relay + Bridge without being an exit node.

The server is located in a network that does not route traffic to Tor guard nodes, I had to work around that using a VPN that succesfully allowed the server to establish Tor circuits. The VPN runs on the gateway and I added a rule to use the VPN as upstream gateway for the traffic coming from the relay and going to the internet.

To add some more complexity, the server is behind a pfsense firewall which I have configured to forward the ORPort to the relay via Port Forwarding. I have also set NAT reflection to “NAT + Proxy” to make sure that the ORPort is reachable from within the LAN.

I can succesfully reach the ORPort from outside - I executed nmap scans from different ISP networks and they consistently show that the port is reachable and open.

The problem is that the relay keeps failing the reachability test, giving me the warning “Your server has not managed to confirm reachability for its ORPort(s)”. Also, to simulate the self-check I used netcat to reach the ORPort from the server itself using its public IP and I was able to comunicate successfully.

I googled around and I couldn’t find much, besides this post from 2022 ( Your server has not managed to confirm reachability for its ORPort(s) - #11 by macrohumanity ). OP seemed to have the same issue and identified that using an upstream VPN was a problem, but I didn’t understand why this may create an issue.

To summarise, I have the following situation

INTERNET <--> pfsense <-- port fwd --> TOR relay server <--> pfsense <--> VPN <--> TOR

Every part of this infrastructure works, but I keep failing the reachability test.

Do you have any idea about the root cause and/or any suggestion to work around this issue?

This is my torrc configuration file

## The IP address or hostname for incoming connections (leave commented and Tor will guess)
Address [REDACTED]

## Set the nickname of this relay
Nickname [REDACTED]

## Set your own contact info
ContactInfo [REDACTED]

# Avoid port 9001 because it's commonly associated with Tor and censors may be scanning the Internet for this port.
ORPort 443 IPv4Only
ControlPort 9696

### Tor bridge
BridgeRelay 1
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
# This port must be externally reachable and must be different from the one specified for ORPort.
# Avoid port 9001 because it's commonly associated with Tor and censors may be scanning the Internet for this port.
ServerTransportListenAddr obfs4 0.0.0.0:8000
# Local communication port between Tor and obfs4.  Always set this to "auto".
# "Ext" means "extended", not "external".  Don't try to set a specific port number, nor listen on 0.0.0.0.
ExtORPort auto


### BANDWIDTH

RelayBandwidthRate 30 MBytes
RelayBandwidthBurst 100 MBytes

SocksPort 0
SocksPolicy reject *

ExitRelay 0
ExitPolicy reject *:*

Log notice file /var/log/tor/notices.log
DataDirectory /var/lib/tor
RunAsDaemon 1

This is my rules.v4 file

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:fail2ban-ssh -

##  Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT

## allow incoming SSH
-A INPUT -p tcp --dport 22 -j ACCEPT

## allow Tor ORPort
-A INPUT -p tcp --dport 443 -j ACCEPT

# Allow Tor Bridge - 8000
-A INPUT -p tcp --dport 8000 -j ACCEPT


## ratelimit ICMP echo, allow all others
-A INPUT -p icmp --icmp-type echo-request -m limit --limit 2/s -j ACCEPT
-A INPUT -p icmp --icmp-type echo-request -j DROP
-A INPUT -p icmp -j ACCEPT

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state INVALID -j DROP

-A fail2ban-ssh -j RETURN

COMMIT

Thanks in advance!
Cheers

2

@0ni0niz3 cool to see that you referred to my past post! I ended up giving up on running my bridge through OpenVPN and I later attempted to run my bridge through Wireguard without luck.
I remember wondering if the third-party VPN/Wireguard server firewall was causing the reachability issue, which would be out of my control.
I will be following any responses to your post - maybe you will find a solution that will inspire me to re-attempt to run my bridge through OpenVPN/wireguard! cheers

3

I am using Wireguard as well, and I can successfully establish a Tor circuit. I can actually reach tor hidden services using the SOCKS proxy exposed by torrc.

I’m not using the VPN public IP because I want to be reachable from my real public IP. Using the VPN IP would require the VPN provider to allow forwarding from their public IP to the VPN client, as you already mentioned.

In addition, this may result in ISPs banning VPN IPs (since they will appear as tor relays), which wouldn’t be nice :slight_smile:

In my case, since Tor relays are blocked at routing level, I understand that it’s very likely I won’t be able to ever be a middle node. However, I feel like I could be an entry node, since the connection [MY NODE] -> [Tor Relays] is allowed via the VPN.

As I mentioned in my previous post, using the “real” public IP of my server, I see that the ports are open and reachable. The problem seems to be in the circuits creation when the server is used as a Relay.

I’m aware that my setup is quite weird and having 2 different public IPs (one for “listening” and one for “connecting to tor”) is probably the root cause of the problem, but I’d really like to understand the reasons behind it :slight_smile: