Matthias Houdek wrote:
Interessanterweise ja. Allerdings dauert es ca. 2,5 Minuten bis das
hostname login: erscheint.
Da würde mich dann doch mal ein Sniffer-Mitschnitt interessieren. Das ist
ja doch zu drollig.
Folgt bald.
Aber irgendwann werden wir uns sicher mit der Hand an die Stirn
Björn Schmidt wrote:
Ping ist aber auch kein TCP. Geht ein Telnet?
Interessanterweise ja. Allerdings dauert es ca. 2,5 Minuten bis das
hostname login: erscheint.
--
Mit freundlichen Gruessen
Bjoern Schmidt
--
Haeufig gestellte Fragen und Antworten (FAQ):
Am Sonntag, 7. November 2004 17:59 schrieb Björn Schmidt:
Björn Schmidt wrote:
Ping ist aber auch kein TCP. Geht ein Telnet?
Interessanterweise ja. Allerdings dauert es ca. 2,5 Minuten bis das
hostname login: erscheint.
Da würde mich dann doch mal ein Sniffer-Mitschnitt interessieren. Das
Bin jetzt erstmal bis einschliesslich Freitag nicht vor Ort und kann
nicht weiter testen. Melde mich dann wieder, vielleicht hast Du
(Matthias) dann ja ein wenig experimentiert und ne Lösung für das
Problem. Bis denn...
--
Mit freundlichen Gruessen
Bjoern Schmidt
--
Haeufig gestellte Fragen und
Am Samstag, 30. Oktober 2004 20:53 schrieb Björn Schmidt:
Matthias Houdek wrote:
iptables -A INPUT -m state --state INVALID -j LOG --log-prefix
INVALID State INPUT
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A OUTPUT -m state --state INVALID -j LOG --log-prefix
INVALID
Matthias Houdek wrote:
Was soll IPSec machen (Tunnel von wo nach wo?)?
Kein Tunnel. Transport Modus, wie hier:
http://www.ipsec-howto.org/x247.html
und diese IPSec-Verbindung soll den gesamten Verkehr zwischen 192.168.1.1
und 192.168.1.2 verschlüsseln?
Ja. Wenn es irgendwann mal funktionieren
Am Sonntag, 31. Oktober 2004 12:43 schrieb Björn Schmidt:
Matthias Houdek wrote:
Was soll IPSec machen (Tunnel von wo nach wo?)?
Kein Tunnel. Transport Modus, wie hier:
http://www.ipsec-howto.org/x247.html
und diese IPSec-Verbindung soll den gesamten Verkehr zwischen
192.168.1.1
Matthias Houdek wrote:
Die IPSec-Frames kommen auf dem Rechner mit der Firewall an und werden
erst nach dem Entpacken zu den verhunzten SSH-Segmenten, die dann
verworfen werden?
Äääh nein. Die Pakete möchten den Firewall-Rechner -von wo aus die Verbindung
aufgebaut werden soll- gerne verlassen
Am Sonntag, 31. Oktober 2004 19:18 schrieb Björn Schmidt:
Matthias Houdek wrote:
Die IPSec-Frames kommen auf dem Rechner mit der Firewall an und
werden erst nach dem Entpacken zu den verhunzten SSH-Segmenten, die
dann verworfen werden?
Äääh nein. Die Pakete möchten den Firewall-Rechner
Matthias Houdek wrote:
nicht das er es benutzt. Na gut, bei älteren Rechnern kann schon die
maximale Übertragungsrate etwas absinken, aber das wäre auch alles.
Naja, das dürfte man wohl bei den meisten Rechnern kaum spüren. Da muss
das Teil ja schon sehr alt ( 3-4 Jahre) sein.
Um genau so ein
Matthias Houdek wrote:
Hm. Es fehlt ein wenig Hintergrund, um mit den paar Schnipseln was
anfangen zu können. Vor allem weiß ich immer noch nicht, wo da IPSec mit
im Spiel ist.
Gut. Ich habe eine funktionierende Firewall die im internen Netz alles erlaubt
was entweder NEW,RELATED oder
Am Samstag, 30. Oktober 2004 14:51 schrieb Björn Schmidt:
Matthias Houdek wrote:
Hm. Es fehlt ein wenig Hintergrund, um mit den paar Schnipseln was
anfangen zu können. Vor allem weiß ich immer noch nicht, wo da IPSec
mit im Spiel ist.
Gut. Ich habe eine funktionierende Firewall die im
Matthias Houdek wrote:
iptables -A INPUT -m state --state INVALID -j LOG --log-prefix INVALID
State INPUT
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A OUTPUT -m state --state INVALID -j LOG --log-prefix
INVALID State OUTPUT
iptables -A OUTPUT -m state --state INVALID -j DROP
Hi,
ich habe hier ein Problem bei dem ich nicht mehr weiter weiß.
Verbindungen zu meinem neuen Router sind Subnetzübergreifend nur
mit IPsec (Transport/ESP) möglich. Das Problem ist das ausgehende,
zu ssh-Verbindungen (andere habe ich noch nicht getestet) gehörende
Pakete nicht durch die Firewall
Am Freitag, 29. Oktober 2004 14:35 schrieb Björn Schmidt:
Hi,
ich habe hier ein Problem bei dem ich nicht mehr weiter weiß.
Verbindungen zu meinem neuen Router sind Subnetzübergreifend nur
mit IPsec (Transport/ESP) möglich. Das Problem ist das ausgehende,
zu ssh-Verbindungen (andere habe ich
Matthias Houdek wrote:
Mit Kommentarzeichen bekomme ich (das Paket wird verworfen da kein
match):
Oct 29 13:51:05 skyron ILLEGAL_PACKET IN= OUT=eth0 MAC= SRC=192.168.1.1
DST=192.168.1.2 LEN=60 TOS=00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=22
DPT=33085 SEQ=104856 ACK=1050690244 WINDOW=5792 ACK
Am Freitag, 29. Oktober 2004 16:14 schrieb Björn Schmidt:
Matthias Houdek wrote:
Mit Kommentarzeichen bekomme ich (das Paket wird verworfen da kein
match):
Oct 29 13:51:05 skyron ILLEGAL_PACKET IN= OUT=eth0 MAC=
SRC=192.168.1.1 DST=192.168.1.2 LEN=60 TOS=00 PREC=0x00 TTL=64 ID=0
DF
Matthias Houdek wrote:
Nein, die Verbindung gilt erst dann als aufgebaut wenn nach dem
Versenden von SYN,ACK ein ACK zurückgekommen ist. Da das SYN,ACK nicht
durchkommt, kann auch kein ACK zurückkommen...
Hier irrt der Björn (evtl.)
Das erste TCP-Paket hat noch kein ACK (woher auch, welches SYN
Björn Schmidt wrote:
ist. Für die Gegenstelle ist sie erst dann ESTABLISHED wenn sie als
Antwort auf das SYN,ACK ein SYN bekommen hat.
Ich meinte natürlich ACK.
--
Mit freundlichen Gruessen
Bjoern Schmidt
--
Haeufig gestellte Fragen und Antworten (FAQ):
Am Freitag, 29. Oktober 2004 18:31 schrieb Björn Schmidt:
Matthias Houdek wrote:
Nein, die Verbindung gilt erst dann als aufgebaut wenn nach dem
Versenden von SYN,ACK ein ACK zurückgekommen ist. Da das SYN,ACK
nicht durchkommt, kann auch kein ACK zurückkommen...
Hier irrt der Björn
20 matches
Mail list logo
