Hi,
how bad is it to simply ignore ORPort/DirPort address mismatch log entry on a relay behind (1:1) NAT? I assume tor figures out the public IPv4 address anyway, no?
The IPv4 ORPort address 192.168.1.1 does not match the descriptor address 1.2.3.4. If you have a static public IPv4 address, use 'Address <IPv4>' and 'OutboundBindAddress <IPv4>'. If you are behind a NAT, use two ORPort lines: 'ORPort <PublicPort> NoListen' and 'ORPort <InternalPort> NoAdvertise'.
I'm explicitly specifying (private) IP addresses in ORPort/DirPort (and OutboundBindAddress) lines to avoid binding to the same ports when running >2 instances (with >1 public IP).
https://github.com/nusenu/ansible-relayor/issues/101
thanks, nusenu
On 23 Jan 2017, at 09:16, nusenu nusenu@openmailbox.org wrote:
Hi,
how bad is it to simply ignore ORPort/DirPort address mismatch log entry on a relay behind (1:1) NAT? I assume tor figures out the public IPv4 address anyway, no?
The IPv4 ORPort address 192.168.1.1 does not match the descriptor address 1.2.3.4. If you have a static public IPv4 address, use 'Address <IPv4>' and 'OutboundBindAddress <IPv4>'. If you are behind a NAT, use two ORPort lines: 'ORPort <PublicPort> NoListen' and 'ORPort <InternalPort> NoAdvertise'.
I'm explicitly specifying (private) IP addresses in ORPort/DirPort (and OutboundBindAddress) lines to avoid binding to the same ports when running >2 instances (with >1 public IP).
https://github.com/nusenu/ansible-relayor/issues/101
thanks, nusenu
What are the exact torrc lines?
I don't think this warning should be triggered in the setup you describe, but I'll need to re-read the code to check.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
I can answer your questions because I'm the one that filed the issue previously referenced by nusenu.
What are the exact torrc lines?
One relay where I see these log messages has a public address of 51.15.48.254 while the relevant torrc lines are as follows:
ORPort 10.8.169.135:443 ORPort [2001:bc8:4700:2300::25:c07]:443 DirPort 10.8.169.135:80 OutboundBindAddress 10.8.169.135
I don't think this warning should be triggered in the setup you describe, but I'll need to re-read the code to check.
I'm not sure of the exact network setup because it's not something I have much visibility into, but the affected relays have a single private IPv4 address and a single public IPv4 address and seem to behave like a 1:1 NAT as far as I can tell.
On 24 Jan 2017, at 12:42, Kevin Beranek kevin@kberanek.com wrote:
I can answer your questions because I'm the one that filed the issue previously referenced by nusenu.
What are the exact torrc lines?
One relay where I see these log messages has a public address of 51.15.48.254 while the relevant torrc lines are as follows:
ORPort 10.8.169.135:443 ORPort [2001:bc8:4700:2300::25:c07]:443 DirPort 10.8.169.135:80 OutboundBindAddress 10.8.169.135
Is the Address option set on this relay? Maybe we need to change this part of the warning:
If you have a static public IPv4 address, use 'Address <IPv4>'
I don't think this warning should be triggered in the setup you describe, but I'll need to re-read the code to check.
I'm not sure of the exact network setup because it's not something I have much visibility into, but the affected relays have a single private IPv4 address and a single public IPv4 address and seem to behave like a 1:1 NAT as far as I can tell.
If the address option isn't set, what does the relay identify as its public IP address in the logs?
Look for log entries about testing ORPort or DirPort reachability, or any log entries containing its public IP address.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
Is the Address option set on this relay?
Address is not set because it is generated from this template, which does not set Address: https://github.com/nusenu/ansible-relayor/blob/dev/templates/torrc.
Maybe we need to change this part of the warning:
If you have a static public IPv4 address, use 'Address <IPv4>'
I'm not quite sure what you're proposing. Are you suggesting dropping just the "and 'OutboundBindAddress <IPv4>'" or the rest of the message?
If the address option isn't set, what does the relay identify as its public IP address in the logs?
Look for log entries about testing ORPort or DirPort reachability, or any log entries containing its public IP address.
It definitely identifies the correct public IP address as you can see from these logs:
Now checking whether ORPort 51.15.48.254:443 and DirPort 51.15.48.254:80 are reachable... (this may take up to 20 minutes -- look for log messages indicating success) ... Self-testing indicates your DirPort is reachable from the outside. Excellent. Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
On 24 Jan 2017, at 14:39, Kevin Beranek kevin@kberanek.com wrote:
Is the Address option set on this relay?
Address is not set because it is generated from this template, which does not set Address: https://github.com/nusenu/ansible-relayor/blob/dev/templates/torrc.
To disable the warning, the template could: * set Address, or * use two ORPort lines: 'ORPort <PublicPort> NoListen' and 'ORPort <InternalPort> NoAdvertise'.
But that requires knowing the external address.
Maybe we need to change this part of the warning:
If you have a static public IPv4 address, use 'Address <IPv4>'
I'm not quite sure what you're proposing. Are you suggesting dropping just the "and 'OutboundBindAddress <IPv4>'" or the rest of the message?
I think the message is fine, it covers the most common cases.
I don't think we can disable the message in your case, without hiding the issue from operators who need to know about address mismatches.
If the address option isn't set, what does the relay identify as its public IP address in the logs?
Look for log entries about testing ORPort or DirPort reachability, or any log entries containing its public IP address.
It definitely identifies the correct public IP address as you can see from these logs:
Now checking whether ORPort 51.15.48.254:443 and DirPort 51.15.48.254:80 are reachable... (this may take up to 20 minutes -- look for log messages indicating success) ... Self-testing indicates your DirPort is reachable from the outside. Excellent. Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Then it's ok to ignore the warning.
It was put there for relay operators whose relay chooses the wrong public address, and they don't notice.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
-
Kevin Beranek -
nusenu -
teor