Transparenter Proxy/Filter bei A1?

[gst]

Ich habe derzeit bei einem A1 Kombipaket Anschluss ein Problem das sehr so aussieht, als würde A1 einen transparenten Proxy für meine ausgehenden Verbindungen verwenden.

Den entsprechenden Anschluss verwende ich ca. 2 mal im Jahr. Das erste mal dieses Jahr (gesamten August über) hat alles problemlos funktioniert. Das zweite mal dieses Jahr (seit 20. Dezember) hat die erste Woche oder so problemlos funktioniert, aber danach sind mir Probleme mit ausgehenden SSH/Mosh Verbindungen ausgefallen.

Hier die Symptome:

- TCP Packets nach draussen auf die meisten externen Portnummern dürften irgendwo gefiltert werden. Mit tcpdump auf einem externen Server sehe ich zwar problemlos alle Web usw. Connections, zu SSH Connection sehe ich aber überhaupt keine Packets (nichtmal SYN). Clientseitige Connection Versuche führen zu einem Timeout.

- Das Problem ist client unabhängig (tritt bei Laptop + Android als Client auf). Ebenfalls ist es serverunabhängig, da alle SSH Verbindungen nach draussen betroffen sein dürften. Bei meinem A1 Modem (Pirelli) habe ich schon sämtliche Firewalls deaktiviert, als auch die Firmware auf die aktuelleste Version (3.2.2) upgegraded - hat aber nicht geholfen.

- Kein Packetloss oder ähnliches. Requests auf Web Ports usw. funktionieren problemlos.

- Nach einem Reboot vom Modem funktionieren Connections meist für ca. eine Minute oder so. Danach tritt das Problem von vorne auf.

- Der nmap Output zu meinem Server ist sehr interessant. Direkt nach einem Reboot vom Modem (wenn Connections funktionieren) sieht er so aus:

Code: Alles auswählen

PORT     STATE    SERVICE
22/tcp   open     ssh
25/tcp   open     smtp
80/tcp   open     http
143/tcp  open     imap
443/tcp  open     https
554/tcp  open     rtsp
555/tcp  open     dsf
587/tcp  open     submission
993/tcp  open     imaps
1076/tcp filtered sns_credit
5222/tcp open     xmpp-client
5269/tcp open     xmpp-server


Der Output dabei ist eine Kombination aus den tatsächlich offenen Ports mit weiteren Ports, die allerdings nicht am Server offen sind (z.B. rtsp/554). Sobald die Connection Probleme anfangen aufzutreten, ändert sich der nmap output folgendermassen (mehrere Male getestet und reproduzierbar):

Code: Alles auswählen

PORT     STATE  SERVICE
20/tcp   closed ftp-data
21/tcp   closed ftp
25/tcp   open   smtp
80/tcp   open   http
110/tcp  closed pop3
143/tcp  open   imap
443/tcp  open   https
465/tcp  closed smtps
554/tcp  open   rtsp
555/tcp  open   dsf
993/tcp  open   imaps
995/tcp  closed pop3s
3128/tcp closed squid-http
8080/tcp closed http-proxy
8443/tcp closed https-alt

- Der Diagnostic Output mit den offenen Verbindungen aus Modem sieht auch "Interessant" aus. Bei Verbindungen auf "offene" Ports die funktionieren sehe ich die folgenden Daten:

LAN: LAN IP vom Client
Modem: Externe IP vom Modem
WAN: Remote Endpunkt der TCP Connection
WAN Schnittstelle: Internet_ATM

Bei Ports die zwar offen sind, die ich aber nicht erwarten würde (weil sie nicht am Remote Server aktiv sind) - z.B. rtsp/554 sehe ich den folgenden Output:

LAN: LAN IP vom Client
Modem: LAN IP vom Client
WAN: Remote Endpunkt der TCP Connection
WAN Schnittstelle: (leer)

Wobei dieser Punkt ev. unabhängig vom eigentlichen Problem ist.

Irgendeine Idee was da der Grund sein könnte? Offenbar ist da irgendwo eine Art transparenter Proxy zwischen mir und dem Endpunkt, mir ist aber derzeit noch unklar ob der Proxy bei A1 liegt oder auf meinem Modem.

[Viennaboy]

Die frage ist verwendest ud wirklich nur ein Modem oder einen Router.

[gst]

Das Pirelli Modem (PRGAV4202N) im Router Modus. Die Clients connecten direkt via WiFi zum Pirelli.

[gst]

Ich hab mir jetzt testweise am Server ein Portforwarding von 8443 (von den Problemen nicht betroffener Port) auf 22 (SSH) angelegt und SSH Connections via diesem Port funktionieren problemlos. Ist jetzt natürlich auch keine langfristige Lösung, bestätigt aber meine Theorie, dass da irgendwas zwischen Client und Server bestimmte Ports filtern dürfte.

[zid]

na, das neue jahr is kaum da, und ich steh schon wieder voll aufm schlauch...

hallo gst,

gehen wir deine tests mal genauer durch:
>"...- Der nmap Output zu meinem Server ist sehr interessant..."
heißt das jetzt, daß von einem rechner aus, der im lan des pires steht, mit nmap auf einen deiner server im wan losgehst? ist das so [1]?
im 2. nmap-protokoll sieht man den tcp/22 nimmer. ich geh, davon aus, daß nmap ihn als "filtered" und net als "closed" einstuft. ist das so? wenn nein, dann hast du mindestens zoff am server.

[1] *falls* ich deinen test richtig behirnt hab, könntest du folgendes versuchen:
1.
du nimmst dir einen freund her, der mit ssh sauber auf deinen server zugreifen kann (am besten andrer provider).
2.
der junge geht mit ssh auf deinen server und startet dort tcpdump mit einem capture filter, also z.b.:

Code: Alles auswählen

'tcp port 22 and not host <ip.von.deinem.freund>'
oder du gehst nur auf die syns und syn-acks des tcp/22 los:
'tcp port 22 and tcp[tcpflags] & tcp-syn != 0'

setzt dein freund keinen filter, dann erzeugt er ein feedbacksystem (der dump vom dump vom dump...) und kann im besten fall nix mehr sehen. und wenns ganz blöd hergeht, hängt sich der server komplett auf- net lachen, hats alles schon gegeben.
3.
wenn das ganze steht, rebootest du dein pire und gehst mit nmap sofort danach nur auf den tcp/22 los, das sollte ja nach deinen beschreibungen kurzzeitig funken.
4.
dein freund sieht dann mim tcpdump deine syns aufm tcp/22, und an der src-ip kann er erkennen, ob die syns direkt von dir kommen oder über einen proxy/maskierenden bouncer/wwi. rennen.


eine andre möglichkeit, das ganze affentheater zumindest verständinsmäßig aufzudröseln, wär der su-mode samt nachgeschaltetem router.

ingesamt glaube ich *persönlich* jetzt weniger an irgendwelche proxies auf seiten der ta, weil sich der aufwand bei low-end produkten (i.e. privatzugängen) schlicht und ergreifend nicht rechnet. es is bekannt, daß bei den privatprodukten der tcp/25 (smtp) aus sicherheitsgründen inbound gesperrt wird, das wars aber auch schon.
ich glaube eher, daß dir das pire in die suppe spuckt. deine 3.2.2 kenn ich zwar nicht- nein, danke-, aber wenns um dilettantismus geht, haben die pire-entwickler mein volles vertrauen. die haben mich diesbezüglich noch nie enttäuscht...

lg & ein gutes neues
zid