Re: iptables ipsec - Schwre Kost...?
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 klatschen
und sagen: Klar, logisch - man sind wir blöd. ;-)
:)
Ich poste hier mal meine Configs, in der Hoffnung dass jemand das Problem
(ssh geht gar nicht, telnet login kommt erst nach 2,5 Minuten) nachvollziehen
und lösen kann:
IPsec-Setup-Howto
==
Im Kernel das hier aktivieren:
Networking support (NET) [Y/n/?] y
*
* Networking options
*
PF_KEY sockets (NET_KEY) [Y/n/m/?] y
IP: AH transformation (INET_AH) [Y/n/m/?] y
IP: ESP transformation (INET_ESP) [Y/n/m/?] y
IP: IPsec user configuration interface (XFRM_USER) [Y/n/m/?] y
Cryptographic API (CRYPTO) [Y/n/?] y
HMAC support (CRYPTO_HMAC) [Y/n/?] y
Null algorithms (CRYPTO_NULL) [Y/n/m/?] y
MD5 digest algorithm (CRYPTO_MD5) [Y/n/m/?] y
SHA1 digest algorithm (CRYPTO_SHA1) [Y/n/m/?] y
DES and Triple DES EDE cipher algorithms (CRYPTO_DES) [Y/n/m/?] y
AES cipher algorithms (CRYPTO_AES) [Y/n/m/?] y
==
racoon installieren.
==
[EMAIL PROTECTED]:/var/log# cat /etc/ipsec.conf
#!/usr/sbin/setkey -f
flush;
spdflush;
spdadd 192.168.1.0/24 192.168.1.0/24 any -P in ipsec esp/transport//require;
spdadd 192.168.1.0/24 192.168.1.0/24 any -P out ipsec esp/transport//require;
[EMAIL PROTECTED]:/var/log# cat /etc/racoon/racoon.conf
pathcertificate /etc/racoon/certs;
listen {
isakmp 192.168.1.1 [500];
}
remote anonymous {
exchange_mode main;
certificate_typex509 ipsec.crt ipsec.key;
verify_cert on;
my_identifier asn1dn;
peers_identifierasn1dn;
proposal {
authentication_method rsasig;
dh_groupmodp1024;
encryption_algorithm3des;
hash_algorithm md5;
}
}
sainfo anonymous {
authentication_algorithmhmac_md5,hmac_sha1;
compression_algorithm deflate;
encryption_algorithm3des;
pfs_group modp1024;
}
Zertifikate erstellen und nach /etc/racoon/certs/ kopieren:
https://kilobyte.dyndns.info/howtos/index.html
Im gleichen Verzeichnis einen SymLink gegen das RootCA erstellen:
ln -s rootCA.crt `openssl x509 -noout -hash rootCA.crt`.0
Fertig. Nach einem Neustart von Racoon und einem setkey -f /etc/ipsec.conf
sollte alles funktionieren, wäre da nicht die --
FIREWALL:
[EMAIL PROTECTED]:/var/log# cat /root/bin/einfacheFirewall
#!/bin/sh
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED,NEW -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED,NEW -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED,NEW -j ACCEPT
=
Mit dieser Firewall funtioniert es einwandfrei:
[EMAIL PROTECTED]:/var/log# cat /root/bin/einfacheFirewall
#!/bin/sh
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED,NEW,INVALID -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED,NEW,INVALID-j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED,NEW, INVALID -j
ACCEPT
--
Mit freundlichen Gruessen
Bjoern Schmidt
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: iptables ipsec - Schwre Kost...?
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): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: iptables ipsec - Schwre Kost...?
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 ist ja doch zu drollig. Aber irgendwann werden wir uns sicher mit der Hand an die Stirn klatschen und sagen: Klar, logisch - man sind wir blöd. ;-) -- Gruß MaxX Hinweis: PMs an diese Adresse werden automatisch vernichtet.
Re: iptables ipsec - Schwre Kost...?
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 Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: iptables ipsec - Schwre Kost...?
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 State OUTPUT iptables -A OUTPUT -m state --state INVALID -j DROP iptables -A FORWARD -m state --state INVALID -j LOG --log-prefix INVALID State FORWARD iptables -A FORWARD -m state --state INVALID -j DROP Ja, gut, das ist doch aber nicht alles. Wer darf denn neue Verbindungen aufbauen? So kann nix gehen. Das ist mir klar. Die paar Zeilen dienen auch nur dazu um zu zeigen dass der Status der Verbindung INVALID ist. Ich könnte die defaultpolicy genauso auf ACCEPT setzen, es würde nichts bringen da die Verbindung immer INVALID ist (nicht NEW oder ESTABLISHED) und somit gedroppt wird. Wenn dieses kleine Beispielscript nicht funktioniert, dann kann mein richtiges erst recht nicht gehen. Um das zu zeigen habe ich das Skript oben erweitert um ... --state NEW -j ACCEPT iptables -vL zeigt dann (etwas menschenfreundlicher als ein Skript): Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- lo any anywhere anywhere 7 1979 ACCEPT all -- anyany anywhere anywhere state RELATED,ESTABLISHED 0 0 LOGall -- anyany anywhere anywhere state INVALID LOG level warning prefix `INVALID State INPUT ' 0 0 DROP all -- anyany anywhere anywhere state INVALID 2 192 ACCEPT all -- anyany anywhere anywhere state NEW Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- anyany anywhere anywhere state RELATED,ESTABLISHED 0 0 LOGall -- anyany anywhere anywhere state INVALID LOG level warning prefix `INVALID State FORWARD ' 0 0 DROP all -- anyany anywhere anywhere state INVALID 0 0 ACCEPT all -- anyany anywhere anywhere state NEW Chain OUTPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- anylo anywhere anywhere 9 4156 ACCEPT all -- anyany anywhere anywhere state RELATED,ESTABLISHED 5 272 LOGall -- anyany anywhere anywhere state INVALID LOG level warning prefix `INVALID State OUTPUT ' 5 272 DROP all -- anyany anywhere anywhere state INVALID 3 721 ACCEPT all -- anyany anywhere anywhere state NEW 5 Pakete im OUTPUT Chain wurden - da INVALID - gedroppt, alles andere akzeptiert. Im log steht dann: Oct 30 14:40:18 gigabyte kernel: INVALID State OUTPUT IN= OUT=eth0 SRC=192.168.1.2 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=17523 DF PROTO=TCP SPT=34246 DPT=22 WINDOW=2372 RES=0x00 ACK PSH FIN URGP=0 Jo, da fehlt ja auch die Hälfte. Mein Fehler, hab nicht alles gepostet. Alle Fehlermeldungen die kommen wenn ich eine ssh-Verbindung öffnen will sind diese: Oct 30 20:37:16 gigabyte kernel: INVALID State OUTPUT IN= OUT=eth0 SRC=192.168.1.2 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=19104 DF PROTO=TCP SPT=32811 DPT=22 WINDOW=1460 RES=0x00 ACK URGP=0 Das ist keine vollständige TCP-Verbindungs-Anforderung. Es fehlen das SYN-Flag und eine SEQ-Number, dafür ist das ACK-Flag zu viel. Die anderen sehen diesbezüglich nicht besser aus. Außerdem - wieso FIN? Das kommt nach einem Timeout oder nach CTRL-C während des Verbindungsaufbaus. Ja, weil ja erst gar keine Verbindung angefordert wird. Ich bin am Rechner 192.168.1.2 eingeloggt und versuche eine ssh Verbindung zu 192.168.1.1 aufzubauen. Hoffe das sind jetzt ausreichend Informationen... ;) Die Firewall läuft auf 192.168.1.2 ? Ja, richtig. Allerdings lief sie während meiner ersten Mails auf 192.168.1.1 Da dort das gleiche Fehlverhalten auftrat und ich nicht immer zum Rechner laufen sollte habe ich sie auf 192.168.1.1 deaktiviert und zum testen nach 192.168.1.2 geholt. Die ssh-Verbindung soll von 192.168.1.2 zu 192.168.1.1 aufgebaut werden. 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? Dann dürften zwischen diesen beiden Rechnern keine UDP- oder TCP-Pakete mehr direkt ausgetauscht werden (außer UPD-500 zu Authentifizierung), sondern nur noch alles über Protokoll 50 bzw. 51 (AH bzw. ESP) geleitet werden
Re: iptables ipsec - Schwre Kost...?
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 sollte gibt es noch ein ippp Device dazu und darüber lasse ich auch nur IPsec zu. Aber das ist im Moment nicht interessant. Dann dürften zwischen diesen beiden Rechnern keine UDP- oder TCP-Pakete mehr direkt ausgetauscht werden (außer UPD-500 zu Authentifizierung), Tun sie auch nicht. sondern nur noch alles über Protokoll 50 bzw. 51 (AH bzw. ESP) geleitet werden (d.h., alle TCP-Segmente sind in das AH/ESP-Segment gekapselt). Der kernel schickt sich die aus den ESP-Paketen entpackten TCP, ...-Pakete selbst nochmal zu. Das kann ich mit tcpdump allerdings nicht sehen weil das kernelintern abläuft. Daraus ziehe ich den Schluss, dass dein IPSec schon mal nicht ordentlich konfiguriert ist, sonst würden keine TCP-22-Segmente (SSH) mehr an den Interfaces auftreten. Du meinst sicher auf dem Draht und nicht an den Interfaces (die Schnittstelle für den sshd). Nene, IPsec ist korrekt konfiguriert. tcpdump -i eth0 (ohne firewall, sad geflushed): === 12:01:46.706851 IP gigabyte.skyron.dyndns.info.isakmp skyron.isakmp: isakmp: phase 2/others ? oakley-quick[E] 12:01:46.784881 IP skyron.isakmp gigabyte.skyron.dyndns.info.isakmp: isakmp: phase 2/others ? oakley-quick[E] 12:01:46.785575 IP gigabyte.skyron.dyndns.info.isakmp skyron.isakmp: isakmp: phase 2/others ? oakley-quick[E] 12:01:50.637071 IP gigabyte.skyron.dyndns.info skyron: ESP(spi=0x0f83d0f2,seq=0x1) 12:01:50.637677 IP skyron gigabyte.skyron.dyndns.info: ESP(spi=0x08303576,seq=0x1) 12:01:50.639757 IP gigabyte.skyron.dyndns.info skyron: ESP(spi=0x0f83d0f2,seq=0x2) 12:01:50.644313 IP skyron gigabyte.skyron.dyndns.info: ESP(spi=0x08303576,seq=0x2) 12:01:50.645537 IP gigabyte.skyron.dyndns.info skyron: ESP(spi=0x0f83d0f2,seq=0x3) ### weitere ESP Pakete tcpdump -i eth0 (mit firewall, sad geflushed): == 12:35:24.005339 IP gigabyte.skyron.dyndns.info.isakmp skyron.isakmp: isakmp: phase 2/others ? oakley-quick[E] 12:35:24.083259 IP skyron.isakmp gigabyte.skyron.dyndns.info.isakmp: isakmp: phase 2/others ? oakley-quick[E] 12:35:24.083929 IP gigabyte.skyron.dyndns.info.isakmp skyron.isakmp: isakmp: phase 2/others ? oakley-quick[E] 12:35:26.019066 IP gigabyte.skyron.dyndns.info skyron: ESP(spi=0x08fc658b,seq=0x1) 12:35:26.019597 IP skyron gigabyte.skyron.dyndns.info: ESP(spi=0x08fa28fc,seq=0x1) 12:35:29.082456 arp who-has gigabyte.skyron.dyndns.info tell skyron 12:35:29.082489 arp reply gigabyte.skyron.dyndns.info is-at 00:02:3f:73:ae:6e 12:35:29.390540 IP skyron gigabyte.skyron.dyndns.info: ESP(spi=0x08fa28fc,seq=0x2) 12:35:35.189706 IP skyron gigabyte.skyron.dyndns.info: ESP(spi=0x08fa28fc,seq=0x3) 12:35:35.389651 IP skyron gigabyte.skyron.dyndns.info: ESP(spi=0x08fa28fc,seq=0x4) 12:35:36.989418 IP skyron gigabyte.skyron.dyndns.info: ESP(spi=0x08fa28fc,seq=0x5) 12:35:47.587909 IP skyron gigabyte.skyron.dyndns.info: ESP(spi=0x08fa28fc,seq=0x6) 12:36:11.584435 IP skyron gigabyte.skyron.dyndns.info: ESP(spi=0x08fa28fc,seq=0x7) die IPsec-Verbindung steht aber. Ping z.B. funktioniert tcpdump -i eth0 (mit firewall, fortsetzung von oben, ICMP statt SSH): = 12:36:16.583551 arp who-has gigabyte.skyron.dyndns.info tell skyron 12:36:16.583585 arp reply gigabyte.skyron.dyndns.info is-at 00:02:3f:73:ae:6e 12:36:23.382700 IP skyron gigabyte.skyron.dyndns.info: ESP(spi=0x08fa28fc,seq=0x8) 12:36:33.399155 IP gigabyte.skyron.dyndns.info skyron: ESP(spi=0x08fc658b,seq=0x2) 12:36:33.399665 IP skyron gigabyte.skyron.dyndns.info: ESP(spi=0x08fa28fc,seq=0x9) 12:36:34.402169 IP gigabyte.skyron.dyndns.info skyron: ESP(spi=0x08fc658b,seq=0x3) 12:36:34.402599 IP skyron gigabyte.skyron.dyndns.info: ESP(spi=0x08fa28fc,seq=0xa) 12:36:35.402937 IP gigabyte.skyron.dyndns.info skyron: ESP(spi=0x08fc658b,seq=0x4) 12:36:35.403370 IP skyron gigabyte.skyron.dyndns.info: ESP(spi=0x08fa28fc,seq=0xb) 12:36:36.403789 IP gigabyte.skyron.dyndns.info skyron: ESP(spi=0x08fc658b,seq=0x5) 12:36:36.404214 IP skyron gigabyte.skyron.dyndns.info: ESP(spi=0x08fa28fc,seq=0xc) 12:36:37.404704 IP gigabyte.skyron.dyndns.info skyron: ESP(spi=0x08fc658b,seq=0x6) 12:36:37.405146 IP skyron gigabyte.skyron.dyndns.info: ESP(spi=0x08fa28fc,seq=0xd) -- Mit freundlichen Gruessen Bjoern Schmidt -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: iptables ipsec - Schwre Kost...?
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 und 192.168.1.2 verschlüsseln? Ja. Wenn es irgendwann mal funktionieren sollte gibt es noch ein ippp Device dazu und darüber lasse ich auch nur IPsec zu. Aber das ist im Moment nicht interessant. Ja. Dann dürften zwischen diesen beiden Rechnern keine UDP- oder TCP-Pakete mehr direkt ausgetauscht werden (außer UPD-500 zu Authentifizierung), Tun sie auch nicht. Doch, lt. deinem IPTables-Log kommen defekte TCP-Port 22-Pakete an eth0 an, und die werden geblockt (da INVALID - sind sie ja auch wirklich). sondern nur noch alles über Protokoll 50 bzw. 51 (AH bzw. ESP) geleitet werden (d.h., alle TCP-Segmente sind in das AH/ESP-Segment gekapselt). Der kernel schickt sich die aus den ESP-Paketen entpackten TCP, ...-Pakete selbst nochmal zu. Das kann ich mit tcpdump allerdings nicht sehen weil das kernelintern abläuft. Ach, du bist auf der Eingangsfirewall? Irgendwie hab ich da wohl was verwechselt. 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? (Stimmt ja, der 2.6er Kernel macht IPSec ja irgendwie ohne separates IPSec-Interface - oder? Ich hab mir das noch gar nicht so richtig angeschaut, bei mir läuft noch alles mit dem 2.4er bestens :-) Daraus ziehe ich den Schluss, dass dein IPSec schon mal nicht ordentlich konfiguriert ist, sonst würden keine TCP-22-Segmente (SSH) mehr an den Interfaces auftreten. Du meinst sicher auf dem Draht und nicht an den Interfaces (die Schnittstelle für den sshd). Nene, IPsec ist korrekt konfiguriert. [...] die IPsec-Verbindung steht aber. Ping z.B. funktioniert Ping ist aber auch kein TCP. Geht ein Telnet? Hm, die Mitschnitte zeigen einem herzlich wenig über den Inhalt der ESP-Segmente. Wenn du mal nur AH machst und dann mit 'nem Sniffer reinschaust. Mich würde mal interessieren, was da im IPSec-Segment überhaupt an Daten übertragen wird. Offensichtlich werden die Daten entweder nicht ordentlich eingepackt oder nicht ordentlich ausgepackt. -- Gruß MaxX Hinweis: PMs an diese Adresse werden automatisch vernichtet (Filter nach /dev/null).
Re: iptables ipsec - Schwre Kost...?
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 (sie schaffen es ja nicht in der _OUTPUT_ Chain Akzeptiert zu werden). Wenn ich das richtig interpretiere sind die Pakete schon kaputt _bevor_ sie verschlüsselt werden. (Stimmt ja, der 2.6er Kernel macht IPSec ja irgendwie ohne separates IPSec-Interface - oder? Genau so ist es. IPsec ist für den normalen User transparent, er merkt nicht das er es benutzt. Na gut, bei älteren Rechnern kann schon die maximale Übertragungsrate etwas absinken, aber das wäre auch alles. Daraus ziehe ich den Schluss, dass dein IPSec schon mal nicht ordentlich konfiguriert ist, sonst würden keine TCP-22-Segmente (SSH) mehr an den Interfaces auftreten. Du meinst sicher auf dem Draht und nicht an den Interfaces (die Schnittstelle für den sshd). Nene, IPsec ist korrekt konfiguriert. [...] die IPsec-Verbindung steht aber. Ping z.B. funktioniert Ping ist aber auch kein TCP. Geht ein Telnet? Kann ich gerade nicht ausprobieren weil es das Ergebnis eines anderen Experimentes verfälschen würde. Hm, die Mitschnitte zeigen einem herzlich wenig über den Inhalt der ESP-Segmente. Wenn du mal nur AH machst und dann mit 'nem Sniffer reinschaust. Das teste ich sobald der Rechner wieder frei ist. Vermutlich wird es nichts bringen da die Pakete scheinbar schon _vor_ der verschlüsselung nicht ganz der Spezifikation entsprechen. Mich würde mal interessieren, was da im IPSec-Segment überhaupt an Daten übertragen wird. Offensichtlich werden die Daten entweder nicht ordentlich eingepackt oder nicht ordentlich ausgepackt. Zu späterer Stunde kann ich mehr dazu sagen... -- Mit freundlichen Gruessen Bjoern Schmidt -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: iptables ipsec - Schwre Kost...?
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 -von wo aus die Verbindung aufgebaut werden soll- gerne verlassen (sie schaffen es ja nicht in der _OUTPUT_ Chain Akzeptiert zu werden). Wenn ich das richtig interpretiere sind die Pakete schon kaputt _bevor_ sie verschlüsselt werden. Gut, dann hab ich das doch richtig im Sinn gehabt. Die Firewall läuft auf dem Rechner, von dem du auch die Verbindung aufbaust. Geht denn ssh via IPSec ohne Firewall? (Stimmt ja, der 2.6er Kernel macht IPSec ja irgendwie ohne separates IPSec-Interface - oder? Genau so ist es. IPsec ist für den normalen User transparent, er merkt 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. [...] die IPsec-Verbindung steht aber. Ping z.B. funktioniert Ping ist aber auch kein TCP. Geht ein Telnet? Kann ich gerade nicht ausprobieren weil es das Ergebnis eines anderen Experimentes verfälschen würde. Hm, die Mitschnitte zeigen einem herzlich wenig über den Inhalt der ESP-Segmente. Wenn du mal nur AH machst und dann mit 'nem Sniffer reinschaust. Das teste ich sobald der Rechner wieder frei ist. Vermutlich wird es nichts bringen da die Pakete scheinbar schon _vor_ der verschlüsselung nicht ganz der Spezifikation entsprechen. _Das_ wäre doch schon mal interessant zu wissen. Ich werde mich morgen auch mal ein wenig hinter IPSec mit dem 2.6er klemmen. Hoffe, ich finde ein wenig Zeit dafür. -- Gruß MaxX Hinweis: PMs an diese Adresse werden automatisch vernichtet (Filter nach /dev/null).
Re: iptables ipsec - Schwre Kost...?
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 Grät geht es hier. Ein P2 mit 233MHz. Das macht sich schon bemerkbar. Bei meinen Tests ist die Rate von ~7MB auf ~600kB gesunken. Der Server soll ein 11MBit WLAN bedienen wo eh nur alle 2 Tage einer eMails abruft, so gesehen ist der schon über dimensioniert... :) Ich werde mich morgen auch mal ein wenig hinter IPSec mit dem 2.6er klemmen. Hoffe, ich finde ein wenig Zeit dafür. Wenn man das einmal gemacht hat kann man IPsec mit dem 2.6er in 5 Minuten startklar machen. Ich wollte eigentlich ein HowTo schreiben, aber solange das mit der Firewall nicht vernünftig läuft... -- Mit freundlichen Gruessen Bjoern Schmidt -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: iptables ipsec - Schwre Kost...?
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 ESTABLISHED als Status hat. Aktiviere ich zusätzlich IPsec, dann haben alle TCP-Pakete die den Rechner verlassen wollen den Status INVALID (das konnte ich gestern noch herausfinden). Aktiviere ich NUR IPsec, funktioniert es natürlich auch. Es hatten schon einige ähnliche Probleme: http://www.linuxforen.de/forums/showthread.php?t=157141 Jedoch haben alle das Problem mit aktivem Masquerading. Das habe ich aber nicht aktiv. Ich habe (noch) einen ganz normalen Rechner nur mit eth0 und lo ohne Forwarding o.ä. Ein/Ausgehende Verbindungen von/nach 192.168.1.0/24 laufen ausschliesslich über IPsec. Selbst mit dieser einfachen firewall bekomme ich keine Verbindung hin: iptables -F iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT 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 iptables -A FORWARD -m state --state INVALID -j LOG --log-prefix INVALID State FORWARD iptables -A FORWARD -m state --state INVALID -j DROP Im log steht dann: Oct 30 14:40:18 gigabyte kernel: INVALID State OUTPUT IN= OUT=eth0 SRC=192.168.1.2 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=17523 DF PROTO=TCP SPT=34246 DPT=22 WINDOW=2372 RES=0x00 ACK PSH FIN URGP=0 Oct 30 14:41:11 gigabyte kernel: INVALID State OUTPUT IN= OUT=eth0 SRC=192.168.1.2 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=17525 DF PROTO=TCP SPT=34246 DPT=22 WINDOW=2372 RES=0x00 ACK PSH FIN URGP=0 Ich bin am Rechner 192.168.1.2 eingeloggt und versuche eine ssh Verbindung zu 192.168.1.1 aufzubauen. Hoffe das sind jetzt ausreichend Informationen... ;) -- Mit freundlichen Gruessen Bjoern Schmidt -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: iptables ipsec - Schwre Kost...?
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 internen Netz alles erlaubt was entweder NEW,RELATED oder ESTABLISHED als Status hat. Aktiviere ich zusätzlich IPsec, dann haben alle TCP-Pakete die den Rechner verlassen wollen den Status INVALID (das konnte ich gestern noch herausfinden). Aktiviere ich NUR IPsec, funktioniert es natürlich auch. Es hatten schon einige ähnliche Probleme: http://www.linuxforen.de/forums/showthread.php?t=157141 Jedoch haben alle das Problem mit aktivem Masquerading. Das habe ich aber nicht aktiv. Ich habe (noch) einen ganz normalen Rechner nur mit eth0 und lo ohne Forwarding o.ä. Ein/Ausgehende Verbindungen von/nach 192.168.1.0/24 laufen ausschliesslich über IPsec. Selbst mit dieser einfachen firewall bekomme ich keine Verbindung hin: iptables -F iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT 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 iptables -A FORWARD -m state --state INVALID -j LOG --log-prefix INVALID State FORWARD iptables -A FORWARD -m state --state INVALID -j DROP Ja, gut, das ist doch aber nicht alles. Wer darf denn neue Verbindungen aufbauen? So kann nix gehen. Im log steht dann: Oct 30 14:40:18 gigabyte kernel: INVALID State OUTPUT IN= OUT=eth0 SRC=192.168.1.2 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=17523 DF PROTO=TCP SPT=34246 DPT=22 WINDOW=2372 RES=0x00 ACK PSH FIN URGP=0 Jo, da fehlt ja auch die Hälfte. Außerdem - wieso FIN? Oct 30 14:41:11 gigabyte kernel: INVALID State OUTPUT IN= OUT=eth0 SRC=192.168.1.2 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=17525 DF PROTO=TCP SPT=34246 DPT=22 WINDOW=2372 RES=0x00 ACK PSH FIN URGP=0 Dito Ich bin am Rechner 192.168.1.2 eingeloggt und versuche eine ssh Verbindung zu 192.168.1.1 aufzubauen. Hoffe das sind jetzt ausreichend Informationen... ;) Die Firewall läuft auf 192.168.1.2 ? Was soll IPSec machen (Tunnel von wo nach wo?)? -- Gruß MaxX Hinweis: PMs an diese Adresse werden automatisch vernichtet (Filter nach /dev/null).
Re: iptables ipsec - Schwre Kost...?
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 iptables -A FORWARD -m state --state INVALID -j LOG --log-prefix INVALID State FORWARD iptables -A FORWARD -m state --state INVALID -j DROP Ja, gut, das ist doch aber nicht alles. Wer darf denn neue Verbindungen aufbauen? So kann nix gehen. Das ist mir klar. Die paar Zeilen dienen auch nur dazu um zu zeigen dass der Status der Verbindung INVALID ist. Ich könnte die defaultpolicy genauso auf ACCEPT setzen, es würde nichts bringen da die Verbindung immer INVALID ist (nicht NEW oder ESTABLISHED) und somit gedroppt wird. Wenn dieses kleine Beispielscript nicht funktioniert, dann kann mein richtiges erst recht nicht gehen. Um das zu zeigen habe ich das Skript oben erweitert um ... --state NEW -j ACCEPT iptables -vL zeigt dann (etwas menschenfreundlicher als ein Skript): Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- lo any anywhere anywhere 7 1979 ACCEPT all -- anyany anywhere anywhere state RELATED,ESTABLISHED 0 0 LOGall -- anyany anywhere anywhere state INVALID LOG level warning prefix `INVALID State INPUT ' 0 0 DROP all -- anyany anywhere anywhere state INVALID 2 192 ACCEPT all -- anyany anywhere anywhere state NEW Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- anyany anywhere anywhere state RELATED,ESTABLISHED 0 0 LOGall -- anyany anywhere anywhere state INVALID LOG level warning prefix `INVALID State FORWARD ' 0 0 DROP all -- anyany anywhere anywhere state INVALID 0 0 ACCEPT all -- anyany anywhere anywhere state NEW Chain OUTPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- anylo anywhere anywhere 9 4156 ACCEPT all -- anyany anywhere anywhere state RELATED,ESTABLISHED 5 272 LOGall -- anyany anywhere anywhere state INVALID LOG level warning prefix `INVALID State OUTPUT ' 5 272 DROP all -- anyany anywhere anywhere state INVALID 3 721 ACCEPT all -- anyany anywhere anywhere state NEW 5 Pakete im OUTPUT Chain wurden - da INVALID - gedroppt, alles andere akzeptiert. Im log steht dann: Oct 30 14:40:18 gigabyte kernel: INVALID State OUTPUT IN= OUT=eth0 SRC=192.168.1.2 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=17523 DF PROTO=TCP SPT=34246 DPT=22 WINDOW=2372 RES=0x00 ACK PSH FIN URGP=0 Jo, da fehlt ja auch die Hälfte. Mein Fehler, hab nicht alles gepostet. Alle Fehlermeldungen die kommen wenn ich eine ssh-Verbindung öffnen will sind diese: Oct 30 20:37:16 gigabyte kernel: INVALID State OUTPUT IN= OUT=eth0 SRC=192.168.1.2 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=19104 DF PROTO=TCP SPT=32811 DPT=22 WINDOW=1460 RES=0x00 ACK URGP=0 Oct 30 20:37:20 gigabyte kernel: INVALID State OUTPUT IN= OUT=eth0 SRC=192.168.1.2 DST=192.168.1.1 LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=19106 DF PROTO=TCP SPT=32811 DPT=22 WINDOW=1460 RES=0x00 ACK URGP=0 Oct 30 20:37:23 gigabyte kernel: INVALID State OUTPUT IN= OUT=eth0 SRC=192.168.1.2 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=19108 DF PROTO=TCP SPT=32811 DPT=22 WINDOW=1460 RES=0x00 ACK FIN URGP=0 Oct 30 20:37:23 gigabyte kernel: INVALID State OUTPUT IN= OUT=eth0 SRC=192.168.1.2 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=19110 DF PROTO=TCP SPT=32811 DPT=22 WINDOW=1460 RES=0x00 ACK PSH FIN URGP=0 Oct 30 20:37:24 gigabyte kernel: INVALID State OUTPUT IN= OUT=eth0 SRC=192.168.1.2 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=19112 DF PROTO=TCP SPT=32811 DPT=22 WINDOW=1460 RES=0x00 ACK PSH FIN URGP=0 Oct 30 20:37:24 gigabyte kernel: INVALID State OUTPUT IN= OUT=eth0 SRC=192.168.1.2 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=19114 DF PROTO=TCP SPT=32811 DPT=22 WINDOW=1460 RES=0x00 ACK PSH FIN URGP=0 Oct 30 20:37:26 gigabyte kernel: INVALID State OUTPUT IN= OUT=eth0 SRC=192.168.1.2 DST=192.168.1.1 LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=19116 DF PROTO=TCP SPT=32811 DPT=22 WINDOW=1460 RES=0x00 ACK PSH FIN URGP=0 Oct 30 20:37:26 gigabyte kernel: INVALID State OUTPUT IN= OUT=eth0 SRC=192.168.1.2
iptables ipsec - Schwre Kost...?
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 kommen, FALLS IPsec aktiviert ist.
Ohne IPsec geht es. Ich benutze das IPsec aus dem Kernel 2.6
Das entscheidende Fragment meines Firewallscriptes:
function INT_IFACE_accept_out()
{
$IPT_CMD -N INT_OUT
$IPT_CMD -A OUTPUT -o $INT_IFNAME -m state --state NEW
-j ULOG --ulog-prefix INT_IFACE_accept_out
$IPT_CMD -A OUTPUT -o $INT_IFNAME -m state --state NEW
-j INT_OUT
# $IPT_CMD -A OUTPUT -o $INT_IFNAME -j ULOG --ulog-prefix INT_IFACE_esp_out
# $IPT_CMD -A OUTPUT -o $INT_IFNAME -j INT_OUT
$IPT_CMD -A INT_OUT -j ACCEPT
}
Entferne ich die Kommentarzeichen funktioniert es und meine log-File meldet:
Oct 29 13:51:55 skyron INT_IFACE_esp_out 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=33087 SEQ=1084138375 ACK=1121257964 WINDOW=5792 ACK SYN URGP=0
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 SYN URGP=0
Die Frage ist also, warum kann ich mit IPsec nicht ohne weiteres auf --state
NEW prüfen. Und wie muß eine Regel aussehen die mit --state NEW einen
Treffer liefert?
--
Mit freundlichen Gruessen
Bjoern Schmidt
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: iptables ipsec - Schwre Kost...?
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 noch nicht getestet) gehörende
Pakete nicht durch die Firewall kommen, FALLS IPsec aktiviert ist.
Ohne IPsec geht es. Ich benutze das IPsec aus dem Kernel 2.6
Das entscheidende Fragment meines Firewallscriptes:
function INT_IFACE_accept_out()
{
$IPT_CMD -N INT_OUT
$IPT_CMD -A OUTPUT -o $INT_IFNAME -m state --state NEW
-j ULOG --ulog-prefix INT_IFACE_accept_out
$IPT_CMD -A OUTPUT -o $INT_IFNAME -m state --state NEW
-j INT_OUT
# $IPT_CMD -A OUTPUT -o $INT_IFNAME -j ULOG --ulog-prefix
INT_IFACE_esp_out # $IPT_CMD -A OUTPUT -o $INT_IFNAME -j INT_OUT
$IPT_CMD -A INT_OUT -j ACCEPT
}
Entferne ich die Kommentarzeichen funktioniert es und meine log-File
meldet:
Oct 29 13:51:55 skyron INT_IFACE_esp_out 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=33087 SEQ=1084138375 ACK=1121257964 WINDOW=5792
ACK SYN URGP=0
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 SYN URGP=0
^^
Das ACK-Bit (Bestätigung) und die ACK-ID sind gesetzt, damit ist kein
Verbindungsaufbau-Paket mehr (--state=NEW), sondern ein Paket einer
etablierten TCP-Verbindung (--state=ESTABLISHED).
Die Frage ist also, warum kann ich mit IPsec nicht ohne weiteres auf
--state NEW prüfen.
Was hat IPSec damit zu tun?
Und wie muß eine Regel aussehen die mit --state
NEW einen Treffer liefert?
...,ESTABLISHED
--
Gruß
MaxX
Hinweis: PMs an diese Adresse werden automatisch vernichtet (Filter
nach /dev/null).
Re: iptables ipsec - Schwre Kost...?
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 SYN URGP=0 ^^ Das ACK-Bit (Bestätigung) und die ACK-ID sind gesetzt, damit ist kein Verbindungsaufbau-Paket mehr (--state=NEW), sondern ein Paket einer etablierten TCP-Verbindung (--state=ESTABLISHED). 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... Damit Du Dich nicht ärgerst habe ich mal eben umgestellt auf --state NEW,ESTABLISHED,RELATED. Ohne Erfolg. Die Frage ist also, warum kann ich mit IPsec nicht ohne weiteres auf --state NEW prüfen. Was hat IPSec damit zu tun? Das ist Teil der Problembeschreibung. Wenn Du mir diese Frage beantworten kannst, wäre ich sicher einen Schritt weiter. -- Mit freundlichen Gruessen Bjoern Schmidt -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: iptables ipsec - Schwre Kost...?
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 PROTO=TCP SPT=22 DPT=33085 SEQ=104856 ACK=1050690244 WINDOW=5792 ACK SYN URGP=0 ^^ Das ACK-Bit (Bestätigung) und die ACK-ID sind gesetzt, damit ist kein Verbindungsaufbau-Paket mehr (--state=NEW), sondern ein Paket einer etablierten TCP-Verbindung (--state=ESTABLISHED). 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 sollte denn da incrementiert werden) - und das wird mit dem --state=NEW erfasst. Alle anderen Pakete laufen für IPTables bereits als ESTABLISHED, auch wenn die eigentliche TCP-Verbindung erst nach abgeschlossenem Hin-Her-Hin endgültig etabliert ist. Damit Du Dich nicht ärgerst habe ich mal eben umgestellt auf --state NEW,ESTABLISHED,RELATED. Ohne Erfolg. Und welche Regel blockt es (du kannst ja bei den Regeln mit entsprechenden Kommentaren Loggen)? Die Frage ist also, warum kann ich mit IPsec nicht ohne weiteres auf --state NEW prüfen. Was hat IPSec damit zu tun? Das ist Teil der Problembeschreibung. Wenn Du mir diese Frage beantworten kannst, wäre ich sicher einen Schritt weiter. Bin ich dazu da deine Hausaufgaben zu machen? ;-) -- Gruß MaxX Hinweis: PMs an diese Adresse werden automatisch vernichtet (Filter nach /dev/null).
Re: iptables ipsec - Schwre Kost...?
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 sollte denn da incrementiert werden) - und das wird mit dem --state=NEW erfasst. Das ist korrekt. Alle anderen Pakete laufen für IPTables bereits als ESTABLISHED, auch wenn die eigentliche TCP-Verbindung erst nach abgeschlossenem Hin-Her-Hin endgültig etabliert ist. Das ist zur Hälfte richtig. Die Verbindung gilt für den Initiator der Verbindung als ESTABLISHED, sobald SYN,ACK als Antwort auf SYN zurückgekommen ist. Für die Gegenstelle ist sie erst dann ESTABLISHED wenn sie als Antwort auf das SYN,ACK ein SYN bekommen hat. Dieses Vereinbarung ist auch bekannt als Three-Way Handshake, RFC793. Damit Du Dich nicht ärgerst habe ich mal eben umgestellt auf --state NEW,ESTABLISHED,RELATED. Ohne Erfolg. Und welche Regel blockt es (du kannst ja bei den Regeln mit entsprechenden Kommentaren Loggen)? Bei mir heisst die Regel SHRED, der entsprechende Kommentar im log lautet ILLEGAL_PACKET (siehe meine erste Mail). Genau genommen ist SHRED eine Regel die alles ungematchte blockt. Die Frage ist also, warum kann ich mit IPsec nicht ohne weiteres auf --state NEW prüfen. Was hat IPSec damit zu tun? Das ist Teil der Problembeschreibung. Wenn Du mir diese Frage beantworten kannst, wäre ich sicher einen Schritt weiter. Bin ich dazu da deine Hausaufgaben zu machen? ;-) Du mußt es nicht tun, aber ich werde Dich nicht aufhalten. ;) Ich vermute dass ich einen Kernelbug erwischt habe... -- Mit freundlichen Gruessen Bjoern Schmidt -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: iptables ipsec - Schwre Kost...?
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): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: iptables ipsec - Schwre Kost...?
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 (evtl.) Das erste TCP-Paket hat noch kein ACK (woher auch, welches SYN sollte denn da incrementiert werden) - und das wird mit dem --state=NEW erfasst. Das ist korrekt. Alle anderen Pakete laufen für IPTables bereits als ESTABLISHED, auch wenn die eigentliche TCP-Verbindung erst nach abgeschlossenem Hin-Her-Hin endgültig etabliert ist. Das ist zur Hälfte richtig. Die Verbindung gilt für den Initiator der Verbindung als ESTABLISHED, sobald SYN,ACK als Antwort auf SYN zurückgekommen ist. Für die Gegenstelle ist sie erst dann ESTABLISHED wenn sie als Antwort auf das SYN,ACK ein SYN bekommen hat. Dieses Vereinbarung ist auch bekannt als Three-Way Handshake, RFC793. Hab ich was anderes gesagt? Das erste Paket, das zurück kommt, enthält ACK und ist damit als ESTABLISHED eingestuft. Die Antwort dann auf der Gegenseite auch. Damit haben alle TCP-Pakete, bei denen ACK richtig gesetzt ist, den Status ESTABLISHED. Und nur das erste Paket hat kein ACK und ist damit NEW. Damit Du Dich nicht ärgerst habe ich mal eben umgestellt auf --state NEW,ESTABLISHED,RELATED. Ohne Erfolg. Und welche Regel blockt es (du kannst ja bei den Regeln mit entsprechenden Kommentaren Loggen)? Bei mir heisst die Regel SHRED, der entsprechende Kommentar im log lautet ILLEGAL_PACKET (siehe meine erste Mail). Genau genommen ist SHRED eine Regel die alles ungematchte blockt. Solltest du differenzieren (zumindest für die Fehlersuche). Irgendwo muss es ja hängen. Die Frage ist also, warum kann ich mit IPsec nicht ohne weiteres auf --state NEW prüfen. Was hat IPSec damit zu tun? Das ist Teil der Problembeschreibung. Wenn Du mir diese Frage beantworten kannst, wäre ich sicher einen Schritt weiter. Bin ich dazu da deine Hausaufgaben zu machen? ;-) Du mußt es nicht tun, aber ich werde Dich nicht aufhalten. ;) Ich vermute dass ich einen Kernelbug erwischt habe... 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. -- Gruß MaxX Hinweis: PMs an diese Adresse werden automatisch vernichtet (Filter nach /dev/null).
