Opened 6 years ago

Closed 2 years ago

#1458 closed defect (fixed)

IPv6 reachable but IPv4 firewalled

Reported by: zzz Owned by: zzz
Priority: minor Milestone: 0.9.20
Component: router/transport Version: 0.9.17
Keywords: Cc:
Parent Tickets: Sensitive: no


Both addresses published (for both transports), console says "OK', RI caps sometimes LR and sometimes just L. UDPTransport and the reachability status indicators don't anticipate this situation. Need to decide how to handle it.


Change History (10)

comment:1 Changed 6 years ago by zzz

related: #1541

comment:2 Changed 6 years ago by zzz

Status: newaccepted

related issue: even if nothing firewalled, NTCP IPv6 address sometimes gets unannounced and doesn't come back, leaving the router with only 3 published addresses, not 4.

fixes coming in 0.9.19-10

comment:3 Changed 6 years ago by zzz

Proposals and discussion of possible fixes, and reachability capabilities in the RI, in #1548

comment:4 Changed 6 years ago by zzz

-10 had a lot of prep but not the fix; hopeful fix in f6c2d469b56b94a25cea334c5e2981ab2e3e5e9e 0.9.19-11

expected -11 behavior:

When it comes up, summary bar will be "OK", published RI will have an "R" cap, and 4 published addresses IPv4/v6 NTCP/SSU. After it figures out v4 is firewalled, summary bar will be "IPv4: Firewalled; IPv6: OK", publised RI will still have an "R" cap, with 3 published addresses: v6 NTCP, v6 SSU, v4 SSU with introducers (ihost0, …)

Tested on various boxes but not behind a CGN.

comment:5 Changed 6 years ago by DjJeshk

You forgot that SSU and NTCP is separate transports like v6 and v4, so you have to put more detailed information what exactly (NTCP or SSU) is firewalled. Looks like you are ignoring the fact that SSU and NTCP can be firewalled independently from each other like ipv6 and ipv4.

Last edited 6 years ago by DjJeshk (previous) (diff)

comment:6 Changed 6 years ago by zzz

Test by OP of -11 shows it does not fix the issue, and may have made things worse. Will announce additional changes here when I have them.

comment:7 Changed 6 years ago by zzz

OP issue should be fixed, in bf2c87c8f2d56a843a23fb749bef5cd5ec510b4c 0.9.19-12. There was a lot more code to do, it wasn't a simple bug, more like -11 wasn't finished.

Tested following cases: IPv4 only w/ UPnP, IPv6 + IPv4 w/ UPnP, v4 firewalled + v6 OK, public v4/v6. Did not test public but firewalled v4 with public v6, which is the OP issue, but fingers crossed.

Not moving ticket to testing state yet, still some cleanup to do.

comment:8 Changed 6 years ago by zzz

-12 did not fix the OP issue. Minor tweaks coming in -13 but they won't fix it either.

While -12 works for me, it doesn't for OP because the PeerTestManager? does not detect firewalled. This is presumably because the CGN (aka AFTR) is doing a 'full-cone' NAT, i.e. "end-point-independent mapping and filtering (EIM/EIF)", not "address-dependent filtering". Not clear why the peer test gets thru the AFTR (and B4) while incoming UDP connections don't.

Alternatives at this point:

  • manual config enhancements (#1541)
  • Figure out some way to change the peer test so it works
  • Declare firewalled if no incoming connection in a long time (30 minutes to 1 hour?)

Last option is a problem because we can't transition back out of it since we will have to turn off peer testing once we go into that state. And we can't currently track 'real' inbound vs. introduced-inbound connections.


Last edited 6 years ago by zzz (previous) (diff)

comment:9 Changed 5 years ago by zzz

See related #1752

comment:10 Changed 2 years ago by zzz

Resolution: fixed
Status: acceptedclosed

I think most of this very old ticket was fixed over the years. See #1752

Note: See TracTickets for help on using tickets.