Generic Proxy

Schon probiert im Generic Proxy 
Internal , 10010 , Host im Inet , 8000
?

Jo, ich hatte gehofft, das es so einfach geht - klappt aber leider nicht (ein allowed Net hab ich auch noch drin). 

Was noch eine weitere Besonderheit ist, ist das das Quellnetz der Packete nicht direkt an der ASG hängt (also nicht aus dem Interfacenetz 'Internal (Network)' sondern die kommen aus einem anderen Subnetz, das die ASG über eine Route erreicht. Das scheint aber prinzipiell zu funktionieren weil der HTTP Proxy funktioniert.

Wenn ich das Allowed Net aus dem Proxy rauskonfiguriere und statt dessen eine PF Regel mach, sehe ich die Packete auch im Log auf dem internen Interface ankommen, aber die Verbindung nach draussen kommt nicht zustande.

Gruß
Manfred

Jo, ich hatte gehofft, das es so einfach geht - klappt aber leider nicht (ein allowed Net hab ich auch noch drin). 

Was noch eine weitere Besonderheit ist, ist das das Quellnetz der Packete nicht direkt an der ASG hängt (also nicht aus dem Interfacenetz 'Internal (Network)' sondern die kommen aus einem anderen Subnetz, das die ASG über eine Route erreicht. Das scheint aber prinzipiell zu funktionieren weil der HTTP Proxy funktioniert.

Wenn ich das Allowed Net aus dem Proxy rauskonfiguriere und statt dessen eine PF Regel mach, sehe ich die Packete auch im Log auf dem internen Interface ankommen, aber die Verbindung nach draussen kommt nicht zustande.

Gruß
Manfred

Funktioniert der Generic Proxy wenn du es aus dem Interfacenetz 'Internal (Network)' probierst ?

Mit tcpdump -np -i any port 8000   or port 10010  auf deiner ASG siehst du, ob die Pakete auf port 10010 korrekt ankommen und auf port 8000 auf der "anderen" seite wieder rausgehen - und ob dein Internet-Rechner dort auch wieder was zuruecksendet. Bist du sicher, dass der Rechner im Internet auf port 8000 ansprechbar ist?
Bitte den output vom tcpdump hier posten!

Funktioniert der Generic Proxy wenn du es aus dem Interfacenetz 'Internal (Network)' probierst ?

Na, das ist doch mal schön zu hören, das es zumindest theoretisch funktionieren soll :-). 

Ja, der Server im Internet antwortet auf 8000 - mein 'altes' Gateway hat die gleiche konfig drin - mit dem kann ich immer schön vergleichen..

Ich werde das morgen mal beides testen und auch gleich mal die 7.501 einspielen (ist noch keine produktive Kiste) und mich dann hier wieder melden. 

Btw: super das einem hier so fix geholfen wird ##thumbs up##

Ich habe jetzt mal den tcpdump auf der ASG und auf meinem alten Gateway laufen lassen. Hier die outputs:

Altes Gateway:
tcpdump -np port 8000 or port 10010
12:04:22.200589 172.24.81.2.1994 > 172.23.1.5.10010: S 2488396507:2488396507(0) win 65535  (DF)
12:04:22.200830 172.23.1.5.10010 > 172.24.81.2.1994: S 126482777:126482777(0) ack 2488396508 win 5840  (DF)
12:04:22.201396 172.24.81.2.1994 > 172.23.1.5.10010: . ack 1 win 65535 (DF)
12:04:22.212647 .1506 > 62.157.211.58.8000: S 4037797754:4037797754(0) win 5840  (DF)
12:04:25.202467 .1506 > 62.157.211.58.8000: S 4037797754:4037797754(0) win 5840  (DF)
12:04:31.201946 .1506 > 62.157.211.58.8000: S 4037797754:4037797754(0) win 5840  (DF)
12:04:43.200898 .1506 > 62.157.211.58.8000: S 4037797754:4037797754(0) win 5840  (DF)
12:05:07.198910 .1506 > 62.157.211.58.8000: S 4037797754:4037797754(0) win 5840  (DF)
12:05:12.449268 172.24.81.2.1994 > 172.23.1.5.10010: P 1:2(1) ack 1 win 65535 (DF)
12:05:12.449309 172.23.1.5.10010 > 172.24.81.2.1994: . ack 2 win 5840 (DF)
12:05:14.572924 172.24.81.2.1994 > 172.23.1.5.10010: P 2:4(2) ack 1 win 65535 (DF)
12:05:14.572965 172.23.1.5.10010 > 172.24.81.2.1994: . ack 4 win 5840 (DF)
12:05:15.313112 172.24.81.2.1994 > 172.23.1.5.10010: P 4:6(2) ack 1 win 65535 (DF)
12:05:15.313147 172.23.1.5.10010 > 172.24.81.2.1994: . ack 6 win 5840 (DF)
12:05:15.493950 172.24.81.2.1994 > 172.23.1.5.10010: P 6:8(2) ack 1 win 65535 (DF)

ASG:
tcpdump -np -i any port 8000 or port 10010
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
12:06:55.234971 IP 172.24.81.2.2003 > 172.23.1.6.10010: S 346262434:346262434(0) win 65535 
12:06:55.235104 IP .2003 > 62.157.211.58.8000: S 346262434:346262434(0) win 65535 
12:06:58.247426 IP 172.24.81.2.2003 > 172.23.1.6.10010: S 346262434:346262434(0) win 65535 
12:06:58.247587 IP .2003 > 62.157.211.58.8000: S 346262434:346262434(0) win 65535 
12:07:04.181935 IP 172.24.81.2.2003 > 172.23.1.6.10010: S 346262434:346262434(0) win 65535 
12:07:04.182078 IP .2003 > 62.157.211.58.8000: S 346262434:346262434(0) win 65535 

Was ich gemacht habe ist ein 'telnet  10010'. Beim alten GW kommt die Verbindung zustande und wenn ich im Telnet etwas eintippe sieht man die Packete im dump. Auf der ASG kommt die Verbindung nicht zustande und ich kann auch nix eintippen (die Server im I-Net sind die Elster Server vom Finanzamt...)

Man sieht in beiden Fällen komischerweise keine Rückpackete kommen?

Viele Grüße
Manfred

I
Was ich gemacht habe ist ein 'telnet  10010'. Beim alten GW kommt die Verbindung zustande und wenn ich im Telnet etwas eintippe sieht man die Packete im dump. Auf der ASG kommt die Verbindung nicht zustande und ich kann auch nix eintippen (die Server im I-Net sind die Elster Server vom Finanzamt...)

Man sieht in beiden Fällen komischerweise keine Rückpackete kommen?

Also wenn ich nur den unteren tcpdump gesehen hätte, hätte ich gesagt: na klar, das kann nicht gehen - die ASG schickt tapfer Pakete raus, aber es kommt nix zurueck vom Elsterserver. Ergo keine Verbindung. Da hätte ich jetzt mal drauf getippt, dass der Server, den du kontaktierst, einfach nicht auf deine Pakete reagiert (wenn ich hier - ganz ohne Generic Proxy und so) diesen Server auf Port 8000 ansprechen versuche, antwortet er mir ebenfalls nicht.
Kann es sein, dass auf dem Server dort deine SOURCE-Ip (also die offizielle IP deiner ASG) hinterlegt ist - und du, wenn du mit der ASG testest, eine andere off. IP hast als mit der anderen "alten" Lösung?

Warum aber auch im tcpdump der "alten" Lösung keine Rückantwortpakete sichtbar sind ist schon sehr misteriös.
Man sieht auch, dass auch dort, wo es anscheinend ja funktioniert, der Verbindungsaufbau fast eine ganze Minute dauert - 12:04:25 geht das erste Paket zur ASG und ein richtiger Kommuniaktionsfluss kommt erst um 12:05:12 zustande...also da ist irgendwo was ganz arg faul. Der tcpdump der "alten" Lösung sieht für mich so aus, als ob da initial irgendein timeout zuschlägt und dann erst gehts richtig los. Kann es sein, dass da nochmal ein weiteres Gateway oder eine weitere Internetzugang existiert, über den dann die Rückpakete tatsaechlich reinkommen?

Ich denke, du  musst erstmal rausfinden, wie die Kommunikation auf der alten Lösung überhaupt zustandekommen kann, und dann kriegst dus auch auf der ASG hin. Es hängt sehr sicher weder an der ASG noch an der Konfiguration, die du auf der ASG gemacht hast, sondern an irgendwas in deinem Netzwerk bzw. auf dem Elsterserver.

Naja - auf der alten Lösung (ist eine Symantec SGS5440) ist auch nicht weiter drin als ein 'Redirect Service' (das ist von der Konfigurationsmöglichkeit sehr ähnlich zum Generic Proxy) und eben eine PF Regel die den Verkehr zulässt (das geht da nicht so schön automatisch wie auf der ASG).

Was ich als nächstes mal testen werde, ist wenn ich mir eine Generic Proxy für z.B. Google oder sowas mache und was dann passiert.

Der Zugang sollte eigentlich auch nicht das Prob sein - die beiden Gateways hängen am gleichen SDSL Router mit verschiedenen IPs - dazwischen ist nix. Was mir aufgefallen ist, ist das das alte GW scheinbar extern ein andere subnetzmaske hat (/24) als wir vom Provider zugewiesen bekommen haben (/29) und ich hab die ASG natürlich erstmal mir der 'richtigen' SNM konfiguriert.

Gruß
Manfred

Kleiner Zwischenstand:

Das Problem scheint wirklich am Elster Protokoll/Programm/Server zu liegen. Es klappt mittlerweile mit dem alten Gateway auch nicht mehr.

Andere Generic Proxy's habe ich inzwischen recht einfach hinbekommen (z.B. von innen auf nen RDP Server draussen oder bestimmten Port von aussen auf nen anderen Port auf nem Server drinnen...).

Ich werde weiter berichten.

Gruß
Manfred

Kleiner Zwischenstand:

Das Problem scheint wirklich am Elster Protokoll/Programm/Server zu liegen. Es klappt mittlerweile mit dem alten Gateway auch nicht mehr.

Gruß
Manfred

Dir ist klar, daß bei Elster zuerst ein Elsterupdate passiert und anschliessend erst ein Elsterupload ?

ElsterUpdate und Elsteruload sind 2 verschiedene Schuhe, die wirst du mit einem generic Proxy nicht abwickeln können.
Früher ging das, aber Elster hat auf Akamai für Update umgestellt.

Wie Ölm geschrieben hat, soll Generic Proxy Verbindungen von Aussen nach Innen ermöglichen, da Elster aber nur rausschickt, fummelst du an der falschen Baustelle rum.
Ich denke dein Problem liegt eher an den wechselnden update Servern.

Hallo zusammen,

nachdem ich mich heute nochmal intensiver mit Elster beschäftigt habe, ist die Lösung fast zu einfach :-). 

Das geht jetzt einfach über den HTTP Proxy -das funktinoierte bisher nicht - die scheinen da recht häufig an der technischen Seite zu schrauben wenn ich mir die ganzen Änderungsankündigungen anschaue.

Was als Problem noch übrig bleibt, ist das das Elster nicht mit dem AD-SSO zusammen funktioniert (ich habe das Auth log jetzt gerade nicht zur Hand, aber da standen die Worte UTF8 und UTF16 drin....). Bisher ist meine Lösung ein eigenes Proxy Profil für die User/Workstations zu machen, das über dem SSO Profil steht und dort die  Basic Auth gegen das AD zu nutzen - was wiederum dazu führt, das meine zwei Backends (AD/RADIUS) immer beide gefragt werden, was ggf. dazu führt, das der User in einem der beiden Dienst wegen fehlerhaften Anmeldeversuchen gesperrt wird. Gabs da nicht mal eine Möglichkeit, das Backend das genutzt werden soll im Dienst (also Proxy oder VPN) zu konfigurieren?

Viele Grüße
Manfred

PS: die ursprüngliche Frage wegen den Generic Proxys hat sich erledigt - das funktioniert wie schon gesagt auch von innen nach aussen wie in der Anleitung beschrieben.

Gabs da nicht mal eine Möglichkeit, das Backend das genutzt werden soll im Dienst (also Proxy oder VPN) zu konfigurieren?

Nein sowas gabs nie und gibts leider auch noch niocht.
Du kannst aber die Reihenfolge konfigurieren, in der die Backend-Server abgefragt werden.
Ich denke, du solltest dein AD immer als erstes fragen, denn ich habe noch nie gehoert, dass ein AD dich sperrt, wenn du einen (nicht-erfolgreichen) LDAP-Bind probierst. Ganz sicher bin ich mir da aber auch nicht.

So hab ich es jetzt auch eingestellt - zuerst AD dann Radius fragen und das scheint auch zu funktionieren - zumindest sieht man im AUTH Log keine negativen Meldungen vom AD (und auch in den Eventlogs des AD Servers nichts) wenn sich ein Radius User anmeldet, des OTP ja vom AD Passwort abweicht - mal sehen was so in den weiteren Tests passiert :-).