× Hier geht es um die Modelle ST 510, ST 546, ST 585, ST 608, TG 585v7 und TG 787. Fragen zu moderneren Geräten von Thomson/Technicolor bzw. zu Pirelli/ADB bitte in der entsprechenden Sektion stellen.

normal Frage Thomson TG585 v7 > Firewall, NAT deaktivieren

Mehr
09 Jan 2010 19:14 - 09 Jan 2010 19:35 #13218 von kernei1
Hallo zid,

hab jetzt mal ein paar riesige Löcher in die Firewall gerissen:

Dieses Bild ist für Gäste verborgen.
Bitte anmelden oder registrieren um das Bild zu sehen.

Dieses Bild ist für Gäste verborgen.
Bitte anmelden oder registrieren um das Bild zu sehen.


Dieses Bild ist für Gäste verborgen.
Bitte anmelden oder registrieren um das Bild zu sehen.

Dieses Bild ist für Gäste verborgen.
Bitte anmelden oder registrieren um das Bild zu sehen.



leider klappts noch immer nicht:
Jan 9 17:23:04 kernel: eth0 setting full-duplex. 
Jan 9 17:23:05 pppd[5943] pppd 2.4.4 started by root, uid 0 
Jan 9 17:23:05 pppd[5943] Using interface ppp0 
Jan 9 17:23:05 pppd[5943] Connect: ppp0 <--> /dev/pts/0 
Jan 9 17:23:05 pptp[5944]: pptp log[main:pptp.c:267] The synchronous pptp option is activated 
Jan 9 17:23:05 pptp[5952]: pptp log[ctrlp_rep:pptp_ctrl.c:251] Sent control packet type is 1 'Start-Control-Connection-Request' 
Jan 9 17:23:05 pptp[5952]: pptp log[ctrlp_disp:pptp_ctrl.c:732] Received Start Control Connection Reply 
Jan 9 17:23:05 pptp[5952]: pptp log[ctrlp_disp:pptp_ctrl.c:766] Client connection established. 
Jan 9 17:23:06 pptp[5952]: pptp log[ctrlp_rep:pptp_ctrl.c:251] Sent control packet type is 7 'Outgoing-Call-Request' 
Jan 9 17:23:06 pptp[5952]: pptp log[ctrlp_disp:pptp_ctrl.c:851] Received Outgoing Call Reply. 
Jan 9 17:23:06 pptp[5952]: pptp log[ctrlp_disp:pptp_ctrl.c:890] Outgoing call established (call ID 0, peer's call ID 0). 
Jan 9 17:23:06 pppd[5943] PAP authentication succeeded 
Jan 9 17:23:06 pppd[5943] local IP address 91.113.114.19 
Jan 9 17:23:06 pppd[5943] remote IP address 62.47.95.239 
Jan 9 17:23:06 pppd[5943] primary DNS address 195.3.96.67 
Jan 9 17:23:06 pppd[5943] secondary DNS address 213.33.98.136 
Jan 9 17:24:06 pptp[5952]: pptp log[logecho:pptp_ctrl.c:670] Echo Request received. 
Jan 9 17:24:06 pptp[5952]: pptp log[ctrlp_rep:pptp_ctrl.c:251] Sent control packet type is 6 'Echo-Reply' 
Jan 9 17:24:26 pptp[5952]: pptp log[ctrlp_disp:pptp_ctrl.c:781] Received Stop Control Connection Request. 
Jan 9 17:24:26 pptp[5952]: pptp log[ctrlp_rep:pptp_ctrl.c:251] Sent control packet type is 4 'Stop-Control-Connection-Reply' 
Jan 9 17:24:26 pptp[5952]: pptp log[callmgr_main:pptp_callmgr.c:253] Closing connection 
Jan 9 17:24:26 pptp[5952]: pptp log[ctrlp_rep:pptp_ctrl.c:251] Sent control packet type is 12 'Call-Clear-Request' 
Jan 9 17:24:26 pptp[5952]: pptp log[pptp_read_some:pptp_ctrl.c:537] read returned zero, peer has closed 
Jan 9 17:24:26 pptp[5952]: pptp log[pptp_read_some:pptp_ctrl.c:537] read returned zero, peer has closed 
Jan 9 17:24:26 pppd[5953] Modem hangup 
Jan 9 17:24:26 pppd[5953] Connect time 1.4 minutes. 
Jan 9 17:24:26 pppd[5953] Sent 1413971036 bytes, received 0 bytes. 
Jan 9 17:24:26 pppd[5953] Connection terminated. 
Jan 9 17:24:28 pptp[5952]: pptp log[pptp_read_some:pptp_ctrl.c:537] read returned zero, peer has closed 
Jan 9 17:24:30 pptp[5952]: pptp log[call_callback:pptp_callmgr.c:77] Closing connection 
Jan 9 17:24:31 pppd[5953] Exit. 
Jan 9 17:24:41 kernel: eth0 setting full-duplex. 
Jan 9 17:24:41 pppd[6711] pppd 2.4.4 started by root, uid 0 
Jan 9 17:24:41 pppd[6711] Using interface ppp0 
Jan 9 17:24:41 pppd[6711] Connect: ppp0 <--> /dev/pts/0 
Jan 9 17:24:41 pptp[6712]: pptp log[main:pptp.c:267] The synchronous pptp option is activated 
Jan 9 17:24:41 pptp[6720]: pptp log[ctrlp_rep:pptp_ctrl.c:251] Sent control packet type is 1 'Start-Control-Connection-Request' 
Jan 9 17:24:41 pptp[6720]: pptp log[ctrlp_disp:pptp_ctrl.c:732] Received Start Control Connection Reply 
Jan 9 17:24:41 pptp[6720]: pptp log[ctrlp_disp:pptp_ctrl.c:766] Client connection established. 
Jan 9 17:24:42 pptp[6720]: pptp log[ctrlp_rep:pptp_ctrl.c:251] Sent control packet type is 7 'Outgoing-Call-Request' 
Jan 9 17:24:43 pptp[6720]: pptp log[ctrlp_disp:pptp_ctrl.c:851] Received Outgoing Call Reply. 
Jan 9 17:24:43 pptp[6720]: pptp log[ctrlp_disp:pptp_ctrl.c:890] Outgoing call established (call ID 0, peer's call ID 0). 
Jan 9 17:24:43 pppd[6711] LCP terminated by peer 
Jan 9 17:24:46 pppd[6711] Connection terminated. 
Jan 9 17:24:46 pptp[6712]: pptp warn[decaps_hdlc:pptp_gre.c:197] short read (-1): Input/output error 
Jan 9 17:24:46 pptp[6712]: pptp warn[decaps_hdlc:pptp_gre.c:209] pppd may have shutdown, see pppd log 
Jan 9 17:24:46 pptp[6720]: pptp log[callmgr_main:pptp_callmgr.c:230] Closing connection 
Jan 9 17:24:46 pptp[6720]: pptp log[ctrlp_rep:pptp_ctrl.c:251] Sent control packet type is 12 'Call-Clear-Request' 
Jan 9 17:24:46 pppd[6711] Modem hangup 
Jan 9 17:24:46 pppd[6711] Exit. 
Jan 9 17:24:46 pptp[6720]: pptp log[ctrlp_disp:pptp_ctrl.c:922] Call disconnect notification received (call id 0) 
Jan 9 17:24:46 pptp[6720]: pptp log[ctrlp_error:pptp_ctrl.c:199] Result code is 4 '(your) Request'. Error code is 0, Cause code is 0 
Jan 9 17:24:46 pptp[6720]: pptp log[call_callback:pptp_callmgr.c:77] Closing connection 
Jan 9 17:24:46 pptp[6720]: pptp log[pptp_conn_close:pptp_ctrl.c:433] Closing PPTP connection 
Jan 9 17:24:46 pptp[6720]: pptp log[ctrlp_rep:pptp_ctrl.c:251] Sent control packet type is 3 'Stop-Control-Connection-Request' 
Jan 9 17:24:46 pptp[6720]: pptp log[ctrlp_disp:pptp_ctrl.c:781] Received Stop Control Connection Request. 
Jan 9 17:24:46 pptp[6720]: pptp log[ctrlp_rep:pptp_ctrl.c:251] Sent control packet type is 4 'Stop-Control-Connection-Reply' 

Jetzt steht nach dem gescheiterten Einwahlversuch etwas mehr im Log.

Werd jetzt den Bug melden.

Danke für deinen Einsatz und deine Hilfe.

//edit:
sourceforge.net/tracker/?func=detail&aid=2928922&group_id=132104&atid=725139
Letzte Änderung: 09 Jan 2010 19:35 von kernei1.

Bitte Anmelden oder Registrieren um der Konversation beizutreten.

Mehr
10 Jan 2010 12:34 #13241 von zid
hallo kernei,

mir ist noch was eingefallen. das ganze ist aber mit vorsicht zu genießen, da ich die efw nicht kenne (bin noch nicht dazugekommen, sie mir anzuschauen).
wenn du den traffic 10.0.0.138 <-> 10.0.0.140 in der eingehenden und ausgehenden firewallkonfiguration übers webgui erlaubst, dann könnte es sein, daß diese regeln in der forward chain gesetzt werden. diese chain ist für den traffic, der weitergeleitet wird, zuständig. für lokale prozesse sind jedoch die input und output chain zuständig, und dort müssen diese regeln gesetzt werden.
es wird bei der efw sicher die möglichkeit geben, mit ssh/telnet auf die shell zu kommen. kannst du mal den output von
#iptables -nvL
posten.

>"...Jetzt steht nach dem gescheiterten Einwahlversuch etwas mehr im Log..."
das sind 2 einwahlversuche. der erste scheitert wegen dem pptp echo request/reply prob. beim 2. geht lcp schief, das kommt manchmal vor und ist kein bug.

>"...Werd jetzt den Bug melden..."
habs schon gesehen. gut, daß du die pcap + logs hinzugefügt hast.

lg
zid

Bitte Anmelden oder Registrieren um der Konversation beizutreten.

Mehr
11 Jan 2010 18:58 #13282 von kernei1
Hallo zid,
hier die gewünschte Ausgabe der iptables:

Dieser Anhang ist für Gäste verborgen.
Bitte anmelden oder registrieren um den Anhang zu sehen.



fg
kernei1

Dieser Beitrag enthält einen Anhang.
Bitte anmelden (oder registrieren) um ihn zu sehen.

Bitte Anmelden oder Registrieren um der Konversation beizutreten.

Mehr
11 Jan 2010 19:07 #13286 von zid
hallo kernei,

ich schaus mir an und melde mich dann. wird etwas dauern.

lg
zid

Bitte Anmelden oder Registrieren um der Konversation beizutreten.

Mehr
12 Jan 2010 20:13 #13306 von zid
hallo kernei,

hab mir jetzt deine iptables angeschaut. die output chain (in deinem fall wichtiger) enthält nur zähler und hat auch noch policy ALLOW -> völlig harmlos. die input chain enthält natürlich aktive targets, ist aber soweit auch ok. somit sollte es von dieser seite her keine probs mit pptp geben.
aufgefallen sind mir aber ein paar stats. die stehen zwar nicht in einem direkten zusammenhang mit deinem prob, sind aber trotzdem interessant. z.b. die output chain:
Chain OUTPUT (policy ACCEPT 1741 packets, 275K bytes)
 pkts bytes target     prot opt in     out     source               destination         
 1609  240K ipac~i     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
 1740  275K CUSTOMOUTPUT  all  --  *      *       0.0.0.0/0            0.0.0.0/0
diese chain enthält 2 gleiche matching-rules mit unterschiedlichen targets. ipac~i ist eine user defined chain, die die (2) passiven zähler von oben enthält, CUSTOMOUTPUT ist eine leere chain. jetzt würde man erwarten, daß hier die stats übereinstimmen. ist aber nicht der fall, genaugenommen sind sie sogar verkehrt- normalerweise sollten die hits bei *gleichen* regeln von oben nach unten monoton fallend sein, nicht unbedingt streng monoton fallend. das gleiche sieht man in der input chain bei den targets ipac~o und REDINPUT. für mich schon seltsam...

lg
zid

Bitte Anmelden oder Registrieren um der Konversation beizutreten.

Mehr
17 Jan 2010 02:14 #13438 von Martin__37
Hallo an die ganze Runde.

Hab das Forum jetzt ca. 2 Stunden abgesucht aber keine Lösung gefunden, deshalb frag ich mal hier, hoffe :blush: es passt zum Thema.

Und zwar kann man doch im Webgui die Firewall konfigurieren, bzw. sich eine eigene Stufe erstellen.
Die Stufe läst sich auch einrichten aber nicht konfigurieren.
Quell und Ziel Schnittstellen kann man einstellen aber bei Dienst ist nur: mgmt_oam_srv_sink zum auswählen.
Bei der FW die ursprünglich drauf war ( welche weiß ich leider nicht mehr ) ist es gegangen.

FW hab ich die 8.6.9.0 drauf, ini hab ich die von zid und die Standart probiert aber immer dasselbe.

Mir geht es nicht hauptsächlich darum die Firewall händisch zu konfigurieren sondern ob da etwas „Faul“ ist.

Ich hoffe ihr könnt mir weiterhelfen.

mfg Martin

Bitte Anmelden oder Registrieren um der Konversation beizutreten.

Moderatoren: andifrm1912enjoyherby68benderrwhomegeko
Ladezeit der Seite: 0.189 Sekunden
Powered by Kunena Forum