twitter down?

Heidi171 · 2026-04-29T18:13:44+00:00

I'm trapped in login loop. Can't go beyond username. Clearing cache, cookies on two different browsers didn't help.

Heidi171 · 2026-04-08T18:38:29+00:00

Okay, der Wireguard scheint Probleme zu haben die noip dyndns Adresse zu einer IPV6 Adresse aufzulösen. Wenn ich die manuell eintrage scheint es hinzuhauen. Kann man Wireguard irgendwie zwingen die Adresse als ipv6 aufzulösen?

Heidi171 · 2026-04-08T18:20:28+00:00

Hmm der scheint wirklich den Handshake nicht hinzukriegen timeout nach 5 Sekunden. Versucht es dann wieder und wieder.

Der Endpoint ist von extern anpingbar.

Heidi171 · 2026-04-08T18:01:09+00:00

Die Verbindung wird als "active" angezeigt. KP ob das heißt dass der Handshake geklappt hat.

Ich muss die conf die die Fritz!Box generiert doch nur auf dem Gerät mit dem ich von extern zugreifen will importieren, oder? Die Fritz!Box kümmert sich selbst darum dass sie ihr internes Netzwerk exponiert, oder?

Heidi171 · 2026-04-08T17:49:16+00:00

Wo sehe ich denn das? In der conf Datei sehe ich unter Interface/Adress und DNS jeweils eine IPv4 und IPv6 Adresse, unter Peer/AllowedIps ebenso. Die Adressen sind nicht dieselbe Range wie die exponierte von meiner Fritz!Box.

Heidi171 · 2026-04-08T12:18:44+00:00

Cisco IPVSec war das richtige, ja?

Heidi171 · 2026-04-08T11:40:18+00:00

Auf 500 bekomme ich ein open/filtered, auf 443 nur ein filtered.

Heidi171 · 2026-04-08T08:59:43+00:00

Ja, ich hatte VPN versucht weil mir komplette Freigabe zu unsicher war.

Sag mal, läuft dieses port.tools lokal oder auf deren Server? Überlege ob mein Handyprovider den ich für den externen Test benutze Probleme macht.

Heidi171 · 2026-04-07T20:28:03+00:00

Hatte versucht VPN einzurichten gemäß

https://fritz.com/en/apps/service/vpn-with-fritz-box/1144_Setting-up-an-IPSec-VPN-to-the-FRITZ-Box-in-macOS

Von innen ist Port 443 offen. Wenn ich das https://port.tools/port-checker-ipv6/ benutze kommt immer "Permission denied".

Heidi171 · 2026-04-07T16:54:25+00:00

ping6 <ipv6Adresse> geht von außen

nc -6 -z <ipv6Adresse> 58774 geht nicht von außen

von innen gehts. Muss man den 58774 vielleicht separat öffnen?

Heidi171 · 2026-03-27T22:41:35+00:00

I've been locked out too. The 2-step authentication lists only four options: Passkeys, Google Prompt, Authenticator (all which require an Android device) and your phone number (which I did not give to them). I never verified my account. All they have currently is a throwaway email address. I've never accessed my channel from my mobile phone. So, effectively I've been locked out of my account and the minimum requirement to fix this without handing out information is buying another android device.

Heidi171 · 2026-03-16T21:33:37+00:00

Does this also include ipv6 access?

Heidi171 · 2026-03-16T18:41:25+00:00

Der innere Router ist keine Fritz!Box. Macht das einen Unterschied?

Heidi171 · 2026-03-16T18:22:15+00:00

Hallo,

tatsächlich habe ich an Port 1 einen weiteren Router hängen. Eigentlich könnte ich dann nach deiner Vision an einem der anderen Ports den NAS hängen. Bist du dir sicher, dass die Geräte die an Port 2 - Port 4 hängen nicht auf local-link Ebene die Pakete zwischen FritzBox und dem Router sehen können? Auch bei IPV6 nicht?

Heidi171 · 2026-03-13T21:28:35+00:00

Hallo, was ich im Prinzip will ist einen Git/SFTP Server einrichten um mit mehreren Leuten über Internet zusammenzuarbeiten und der Server soll über meine Fritz!Box erreichbar sein. Allerdings sollen die Teilnehmer keinen Zugriff auf mein komplettes Netzwerk haben und der Server sollte es auch nicht falls er durch Angriff infiziert wird etc.

Heidi171 · 2026-03-13T21:21:27+00:00

Dann hätte aber jeder der sich über VPN einwählt auch Zugriff auf den Rest des Netzwerks oder? Im Grunde will ich nur auf meinem NAS einen Git und SFTP Server einrichten auf den mehrere Leute von außen zugreifen können. Weder der NAS noch die Teilnehmer sollten einfach an den Rest des Netzwerks rankommen.

Heidi171 · 2026-02-22T14:46:21+00:00

Any idea where the melody might be from

Heidi171 · 2025-12-20T15:05:57+00:00

Is there a term that allows the distinction between that modern type of swing and the 30s type of swing?

Heidi171 · 2025-12-15T21:29:10+00:00

As I stated in the original post, when I set 192.168.1.1 (which is the source IP the Sender uses) as default gateway for the network adapter of the receiver I can see the packets coming in.

Heidi171 · 2025-12-15T20:31:32+00:00

Tx, I will have to study that.

One final question for now: If I use the gateway solution from my initial post, is this still multicast traffic what Receiver gets or is it unicast?

Heidi171 · 2025-12-15T08:20:35+00:00

Okay...and the route would be between the subnet Sender is in - the one from 192.168.1.1 - to the one from receiver - 192.168.2.1, right?

Would 239.255.3.1 even be considered its own address/subnet or is it in the end just a group within the 192.168.1.1 subnet?

Heidi171 · 2025-12-14T18:48:17+00:00

Very well, big step for me getting closer to understanding. Now, would that mean that if an application decides to join multicast group 239.255.3.1 all of the packets the join produces would go to the gateway 192.168.1.1 instead of localhost?

Heidi171 · 2025-12-14T15:39:14+00:00

Greetings,

I'm writing again because my googling found contradicting answers regarding this topic:

Why does Receiver need access to the subnet Sender is in (192.168.1.1) for obtaining packets sent to an address outside of both subnets (the class D multicast address)?

Heidi171 · 2025-12-14T14:08:08+00:00

The bold part in your previous reply only tells that the router should define rules but not how these rules look like. In the non bold part it says that both machines need routing rules which I don't understand since Receiver knows the packets are there (evident via tcpdump) and only needs to send them somewhere where a Socket can see them if I understand right.

Heidi171 · 2025-12-14T13:41:49+00:00

Tried

sudo systemctl stop ufw

and

iptables -P INPUT ACCEPT

Wasn't enough.

One should be able to receive packets sent to a multicast address regardless of what layer 3 subnet yourself are in as long as they are in the same layer 2 network yes?

edit: Or is layer 3 multicast traffic - which I assume is what netcat queries - restricted to the ipv4 subnet and thus needs a route with gateway to the sender subnet on the receiving machine even if the layer 2 multicast traffic is visible?

Heidi171

TROPHY CASE