September 2001 - openSUSE Security - openSUSE Mailing Lists

SuSE Security Announcement: nkitb/nkitserv/telnetd
by Sebastian Krahmer 03 Sep '01

03 Sep '01

-----BEGIN PGP SIGNED MESSAGE----- ______________________________________________________________________________ SuSE Security Announcement Package: nkitb/nkitserv/telnetd Announcement-ID: SuSE-SA:2001:029 Date: Mon Sep 3 12:55:58 MEST 2001 Affected SuSE versions: [6.1, 6.2,] 6.3, 6.4, 7.0, 7.1, 7.2 Vulnerability Type: remote code execution Severity (1-10): 8 SuSE default package: yes Other affected systems: All UN*X Systems shipping BSD derived telnetd Content of this advisory: 1) security vulnerability resolved: Buffer overflow in in.telnetd problem description, discussion, solution and upgrade information 2) pending vulnerabilities, solutions, workarounds 3) standard appendix (further information) ______________________________________________________________________________ 1) problem description, brief discussion, solution, upgrade information The telnet server which is shipped with SuSE distributions contains a remotely exploitable buffer-overflow within its telnet option negotiation code. This bug is wide-spread on UN*X systems and affects almost all implementations of telnet daemons available. SuSE 7.2 distribution ships the telnet-server package which contains the vulnerable telnet daemon. This package has been fixed. The SuSE Linux distributions 6.3 and 6.4 contain versions and implementations of the telnet-daemon that are vulnerable, but the complexity of the code requires a full source code audit of the software. In order not to further delay the release of the packages for the SuSE Linux 7.x distributions, we recommend to disable the telnet daemon on the 6.x distributions. This can be done by commenting out the line in /etc/inetd.conf that starts with "telnet", and then reloading the inetd configuration using the command "killall -1 inetd". Another option is to not start the inetd in the first place if you do not need any of the services provided by the inetd daemon. Disabling inetd permanently involves killing the running inetd process ("killall -TERM inetd") and setting the variable START_INETD in /etc/rc.config to "no" (as opposed to "yes"). Disabling the telnet service is the preliminary solution/workaround against the problems with the telnetd daemon. We hope to be able to provide a better solution. The SuSE Linux distributions 7.0, 7.1 and 7.2 have similar implementations of in.telnetd, and for all of these distributions there are update packages available. Please note that the package that contains the /usr/sbin/in.telnetd program (the server program) has changed over the different releases of the SuSE Linux distribution. In the 7.0 and 7.1 distributions the package is called "nkitserv". The 7.2 distribution lists the telnet server in the package "telnet-server". Please download the packages and verify them as described in section 3. After successfull authentication you can update your packages with the command `rpm -Uhv file.rpm'. Further action should not be necessary to activate the update since the in.telnetd daemon is started from a new by inetd upon every accepted connection from the network. Regardless of the availiability of fixed packages of the telnet-daemon, SuSE Security strongly recommend to disable the telnet service if you do not use it. In addition to that, only cryptographically protected protocols such as secure shell (ssh, package openssh) can be an efficient countermeasure against sniffing and spoofing type attacks. Due to significantly more comfort (such as X11-forwarding, multiple authentication methods, ...), the transition to ssh should be worth the effort in any case. i386 Intel Platform: SuSE-7.2 ftp://ftp.suse.com/pub/suse/i386/update/7.2/n1/telnet-server-1.0-69.i386.rpm 0adc05af9762bd4c63eee464ca3131d1 source rpm: ftp://ftp.suse.com/pub/suse/i386/update/7.2/zq1/telnet-1.0-69.src.rpm fe313553d1a6f022c7eb2f87ccd6772f SuSE-7.1 ftp://ftp.suse.com/pub/suse/i386/update/7.1/n1/nkitserv-2001.8.14-0.i386.rpm e0636eec04ccf2129b0e2ea0ee40c231 source rpm: ftp://ftp.suse.com/pub/suse/i386/update/7.1/zq1/nkitb-2001.8.14-0.src.rpm 57760fcd8e064e89591203f7ba9adefc SuSE-7.0 ftp://ftp.suse.com/pub/suse/i386/update/7.0/n1/nkitserv-2001.8.16-0.i386.rpm e8a859d5a648a572fc08628247c1e2d6 source rpm: ftp://ftp.suse.com/pub/suse/i386/update/7.0/zq1/nkitb-2001.8.16-0.src.rpm 33d4abc52926ac957f21b8c8aae7adce Sparc Platform: SuSE-7.1 ftp://ftp.suse.com/pub/suse/sparc/update/7.1/n1/nkitserv-2001.8.14-0.sparc.… 3ef64d1cae35be51c9eff9bebcf4cf79 source rpm: ftp://ftp.suse.com/pub/suse/sparc/update/7.1/zq1/nkitb-2001.8.14-0.src.rpm 4cb76a16bd2f53c37a7cee728ea21c81 SuSE-7.0 ftp://ftp.suse.com/pub/suse/sparc/update/7.0/n1/nkitserv-2001.8.16-0.sparc.… f4901a4a271657d0379aff114d30b912 source rpm: ftp://ftp.suse.com/pub/suse/sparc/update/7.0/zq1/nkitb-2001.8.16-0.src.rpm ad909d8e3d2d0a617a5a9f6e3d7cd74d AXP Alpha Platform: SuSE-7.1 ftp://ftp.suse.com/pub/suse/axp/update/7.1/n1/nkitserv-2001.8.14-0.alpha.rpm efad3412a8d333947bcf74695c023ea8 source rpm: ftp://ftp.suse.com/pub/suse/axp/update/7.1/zq1/nkitb-2001.8.14-0.src.rpm 94d0dba0396e41b4afbd3ef61c4fd8aa SuSE-7.0 ftp://ftp.suse.com/pub/suse/axp/update/7.0/n1/nkitserv-2001.8.16-0.alpha.rpm 934525486e72a5cc98736f4cb1217f93 source rpm: ftp://ftp.suse.com/pub/suse/axp/update/7.0/zq1/nkitb-2001.8.16-0.src.rpm a6623ff6d9439dea40f24ff35acefe99 Power PC Platform: SuSE-7.1 ftp://ftp.suse.com/pub/suse/ppc/update/7.1/n1/nkitserv-2001.8.14-0.ppc.rpm 4da51d1a38095e81ee389094b0f21160 source rpm: ftp://ftp.suse.com/pub/suse/ppc/update/7.1/zq1/nkitb-2001.8.14-0.src.rpm 499b282f614835fe7a7b1a9ab039c56d SuSE-7.0 ftp://ftp.suse.com/pub/suse/ppc/update/7.0/n1/nkitserv-2001.8.16-0.ppc.rpm 262f3fc3653042976c8cc36a2cd7e44d source rpm: ftp://ftp.suse.com/pub/suse/ppc/update/7.0/zq1/nkitb-2001.8.16-0.src.rpm 7cba8393bb8a71cf4d39fb480a71b42e ______________________________________________________________________________ 2) Pending vulnerabilities in SuSE Distributions and Workarounds: - w3m The w3m browser contains a buffer-overflow which allows remote-attackers to execute arbitrary code or to crash the w3m web-client when viewing special crafted sites. Please update to the newest w3m packages available on the ftp-server. - dip The dip program is executable as setuid root program for users in the "dialout" group, a privilege that has been issued by the administrator for a trusted user group. This bug will be corrected in future releases of the SuSE Linux distribution. ______________________________________________________________________________ 3) standard appendix: authenticity verification, additional information - Package authenticity verification: SuSE update packages are available on many mirror ftp servers all over the world. While this service is being considered valuable and important to the free and open source software community, many users wish to be sure about the origin of the package and its content before installing the package. There are two verification methods that can be used independently from each other to prove the authenticity of a downloaded file or rpm package: 1) md5sums as provided in the (cryptographically signed) announcement. 2) using the internal gpg signatures of the rpm package. 1) execute the command md5sum <name-of-the-file.rpm> after you downloaded the file from a SuSE ftp server or its mirrors. Then, compare the resulting md5sum with the one that is listed in the announcement. Since the announcement containing the checksums is cryptographically signed (usually using the key security(a)suse.de) the checksums show proof of the authenticity of the package. We disrecommend to subscribe to security lists which cause the email message containing the announcement to be modified so that the signature does not match after transport through the mailing list software. Downsides: You must be able to verify the authenticity of the announcement in the first place. If RPM packages are being rebuilt and a new version of a package is published on the ftp server, all md5 sums for the files are useless. 2) rpm package signatures provide an easy way to verify the authenticity of an rpm package. Use the command rpm -v --checksig <file.rpm> to verify the signature of the package, where <file.rpm> is the filename of the rpm package that you have downloaded. Of course, package authenticity verification can only target an uninstalled rpm package file. Prerequisites: a) gpg is installed b) The package is signed using a certain key. The public part of this key must be installed by the gpg program in the directory ~/.gnupg/ under the user's home directory who performs the signature verification (usually root). You can import the key that is used by SuSE in rpm packages for SuSE Linux by saving this announcement to a file ("announcement.txt") and running the command (do "su -" to be root): gpg --batch; gpg < announcement.txt | gpg --import SuSE Linux distributions version 7.1 and thereafter install the key "build(a)suse.de" upon installation or upgrade, provided that the package gpg is installed. The file containing the public key is placed at the toplevel directory of the first CD (pubring.gpg) and at ftp://ftp.suse.com/pub/suse/pubring.gpg-build.suse.de . - SuSE runs two security mailing lists to which any interested party may subscribe: suse-security(a)suse.com - general/linux/SuSE security discussion. All SuSE security announcements are sent to this list. To subscribe, send an email to <suse-security-subscribe(a)suse.com>. suse-security-announce(a)suse.com - SuSE's announce-only mailing list. Only SuSE's security annoucements are sent to this list. To subscribe, send an email to <suse-security-announce-subscribe(a)suse.com>. For general information or the frequently asked questions (faq) send mail to: <suse-security-info(a)suse.com> or <suse-security-faq(a)suse.com> respectively. =================================================== SuSE's security contact is <security(a)suse.com>. The <security(a)suse.com> public key is listed below. =================================================== ______________________________________________________________________________ The information in this advisory may be distributed or reproduced, provided that the advisory is not modified in any way. In particular, it is desired that the cleartext signature shows proof of the authenticity of the text. SuSE GmbH makes no warranties of any kind whatsoever with respect to the information contained in this security advisory. Type Bits/KeyID Date User ID pub 2048R/3D25D3D9 1999-03-06 SuSE Security Team <security(a)suse.de> pub 1024D/9C800ACA 2000-10-19 SuSE Package Signing Key <build(a)suse.de> - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org mQENAzbhLQQAAAEIAKAkXHe0lWRBXLpn38hMHy03F0I4Sszmoc8aaKJrhfhyMlOA BqvklPLE2f9UrI4Xc860gH79ZREwAgPt0pi6+SleNFLNcNFAuuHMLQOOsaMFatbz JR9i4m/lf6q929YROu5zB48rBAlcfTm+IBbijaEdnqpwGib45wE/Cfy6FAttBHQh 1Kp+r/jPbf1mYAvljUfHKuvbg8t2EIQz/5yGp+n5trn9pElfQO2cRBq8LFpf1l+U P7EKjFmlOq+Gs/fF98/dP3DfniSd78LQPq5vp8RL8nr/o2i7jkAQ33m4f1wOBWd+ cZovrKXYlXiR+Bf7m2hpZo+/sAzhd7LmAD0l09kABRG0JVN1U0UgU2VjdXJpdHkg VGVhbSA8c2VjdXJpdHlAc3VzZS5kZT6JARUDBRA24S1H5Fiyh7HKPEUBAVcOB/9b yHYji1/+4Xc2GhvXK0FSJN0MGgeXgW47yxDL7gmR4mNgjlIOUHZj0PEpVjWepOJ7 tQS3L9oP6cpj1Fj/XxuLbkp5VCQ61hpt54coQAvYrnT9rtWEGN+xmwejT1WmYmDJ xG+EGBXKr+XP69oIUl1E2JO3rXeklulgjqRKos4cdXKgyjWZ7CP9V9daRXDtje63 Om8gwSdU/nCvhdRIWp/Vwbf7Ia8iZr9OJ5YuQl0DBG4qmGDDrvImgPAFkYFzwlqo choXFQ9y0YVCV41DnR+GYhwl2qBd81T8aXhihEGPIgaw3g8gd8B5o6mPVgl+nJqI BkEYGBusiag2pS6qwznZiQEVAwUQNuEtBHey5gA9JdPZAQFtOAf+KVh939b0J94u v/kpg4xs1LthlhquhbHcKNoVTNspugiC3qMPyvSX4XcBr2PC0cVkS4Z9PY9iCfT+ x9WM96g39dAF+le2CCx7XISk9XXJ4ApEy5g4AuK7NYgAJd39PPbERgWnxjxir9g0 Ix30dS30bW39D+3NPU5Ho9TD/B7UDFvYT5AWHl3MGwo3a1RhTs6sfgL7yQ3U+mvq MkTExZb5mfN1FeaYKMopoI4VpzNVeGxQWIz67VjJHVyUlF20ekOz4kWVgsxkc8G2 saqZd6yv2EwqYTi8BDAduweP33KrQc4KDDommQNDOXxaKOeCoESIdM4p7Esdjq1o L0oixF12CohGBBARAgAGBQI7HmHDAAoJEJ5A4xAACqukTlQAoI4QzP9yjPohY7OU F7J3eKBTzp25AJ42BmtSd3pvm5ldmognWF3Trhp+GZkBogQ57vSBEQQAk/GN+ftr 7+DBlSoixDDpfRnUk+jApGEt8hCnrnjVnPs/9Cr33+CXLQbILOO7Y5oiPbJdHh45 t4E0fKyLVzDerCRFB1swz/mNDxT26DLysdBV5fwNHTPhxa67goAZVrehQPqJEckk IpYriOaYcKpF3n5fQIZMEfMaHEElQhcXML8AoJVXDkJYh7vI8EUB8ZURNLZMEECN A/sH0MCnb4Q6ZcRyeZ3+1PHP8hP73b6TepRdLZhaylwVF/iu7uIn62ZUL4//NTOC DY7V63qg4iba/fUbOsWtEnGaiE7mQuAlsSWvRspwRA9/g9rdVf3/JdLJrLmKBThe yG+PSJE3W7cAE4ZWafGxIRCwXhmj3TQnJn2euqylHRubEQP/aL53NZK0kBdvrKgf f6O8Of6tqoss8Dkk55I7QVFSp+My1Dn+mngQKFejTAgtyo/WmR3wPjQ9HoT2lRiY I2lTRYT4uMdHuwVC3b4DqAKmoy375FERwHkrMVyKBJslv8QtbAWw5A1CAUseaHo+ 91wmYJ4/4p6YUahqbG/tZyhbxfq0KFN1U0UgUGFja2FnZSBTaWduaW5nIEtleSA8 YnVpbGRAc3VzZS5kZT6IXAQTEQIAHAUCOe70gQUJA8JnAAQLCgMEAxUDAgMWAgEC F4AACgkQqE7a6JyACspfLACffAYA+NM8NBhyRyH+nTX58CNjwLIAoIx9fj52BJe0 xY7WbKoXs1+72b2AiEYEEBECAAYFAjpwXlIACgkQnkDjEAAKq6TczgCgi+ddhWb7 +FWcfeE6WwPZccqAHowAnjjtRyGwHLQHr5OTFAYTXi2Wv6jNiQEVAwUQOnBgb3ey 5gA9JdPZAQE1pwf/QJ+b34lFBNVUJ7fk/xGJJREt7V12iSafaRzGuH8xWvIz1bb+ VARxnnt16FDQ1cDNjoEhCEmcW83Vxp6iJXE9PE8wVA/Yue/bon5JS7J69+UiQ2eq 2pudfwljp52lYVM53jgPYEz0q/v3091nlZ8CYkAkN9JDS1lV1gEzJ7J0+POngDpU +lDQT2EC6VKaxeWK8pNt6UFDwICRDQxKnlOoiDvTrdWT7QdJZ4sPv8Qotdw9+tKN bWQ2DqdIRxyTdw9xDfAtcj6mXeQr7852Lwem1gSKVnEYHZ9g1FTJqVOutY8KhpUc 9RfOCRv8XuIxrs4KSbfSF0s8qIRCQelxufg9AbkCDQQ57vSSEAgAhJHQTejMX+Vr 6g1pHDEcusJ63fQ2CfFFE5iE9okH9O7UVCiSfb9CV38dmeHdPCEEjDUWquFYEnvj 3WICMtH249t1Ymuf4Du3yRKQ9oXdn/qTJzlrx9qzjiG3mH7ocwHOgUIwCrZoEdBE VE2n0zPVm+hddwjWWTWXw6pxQz+i9dsN89xexRV5M9O0bNwCLaNWX2GXeLAkqTK/ 9EuZy6x2yLxi6du9YYUAXkZpqBhCjtiUXpRoFCdglMznbcAyCk9C2wqb2j/D1Z2B eSBaGCSFkR6pRLebnE17LWcu72Iy+r0z+JecbPiyDpDZj4apn7IC81aNFGi7fNIT sHODbwwjiwADBgf/YPvVdzkc8OC7ztacEWCanwylKvxCdKzTDA+DfES6WUYShyiV JvZzRy25LJ5WcK20kzOS6Qv1OrIXiz/pdGy1aKtJZrAnFEsofpmOj8VoqyyFgp/y AGQBp12+mXek7SCZRhuqalDfEMRiWEJ6J5dLkyShyRDWyPbFh0HXE7QTHN+IKKxx QqNQXL6Z3NSxS61p+5n6BseiDUI39xxkKTFwFrkgUIc5Gs2Or2lhaWvGwSfoCmwb sklszZt6xbU+R0SjFqTvjPWx6eHfqbmNC9WMDdTjGrXDDKXFp2aYlokfN6It9vsb VlGNlOwHt/JjGoPMxW6Xqj0FLA7/VewgCdXW64hMBBgRAgAMBQI57vSSBQkDwmcA AAoJEKhO2uicgArKSyIAmwUHf/vtKQfcmVg4asR7U6XQl0bAAJ4pO22B5U8UH6IY l2LBCXFqw5+5fA== =Jnnf - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBO5N83Xey5gA9JdPZAQGL3wf/Y9JWafwyYG1XUd5Li95aLdQ4zGDn2DbO o4iJonbvJd5ASsm0bkLIYCfoylkQh/Tc1VxXberIwUSf3NnJ/65kU+Lzn4jvTpMB PZm2QnK9VXukXbvibgamrbiDfSlySfoPD/jJWzTUnugJwZhLDIx3ZL0T9pHvUWOz i4VoK2o70z0dzKKb1YGRZQIaBCZHLm17yWMavEXewHCFJNMYfGT7s/ZajA7FFMXS gFzm7cE+RnykKeMG2Vf53/igoDFrHCiPr8wXEbJu5mbANH9MmGKIpQYdROwKodyk gAFUjXko2fdtkG5HFhlQWXvrHH/ZmZXzWWbp5g5DQ+Uqr3jW6t328A== =AmuR -----END PGP SIGNATURE----- -- ~ ~ perl self.pl ~ $_='print"\$_=\47$_\47;eval"';eval ~ krahmer(a)suse.de - SuSE Security Team ~

1 0

Re: [suse-security] ssh-incompatibility ?
by michael.ryan＠storm.ie 03 Sep '01

03 Sep '01

Install the OpenSSH rpm on the client and use it to connect to the server (afaik the SSH and OpenSSH versions are not compatible) Regards, Michael

1 0

personal firewall and netdate
by Brian Galbraith 03 Sep '01

03 Sep '01

Hi folks I don't know a lot about firewalls so please be gentle! I run the personal fire wall which meets my requirements admirably. However if I wish to set my system clock using netdate.....currently I turn the fire wall off ...log in....set the time...log off, switch on the firewall,and redial. Is there any way to change the personal fire wall to allow connection to the ntp server....and if so....what values do I change? TIA Brian -- Brian Galbraith | GnuPG 1.0.6 | SuSE Linux 7.2-2.4.9 PGP Key 0x8232434C http://www.culcreuch.org.uk ICQ# 110426381 Yahoo Messenger ID: bagalbraith

2 1

AW: [suse-security] automatic backups over ssh/scp
by My PC, Payreder Roman 03 Sep '01

03 Sep '01

Hi, Perhaps you could have a look at: http://freshmeat.net/projects/rsync-backup/ br, Roman * teo(a)gecadsoftware.com wrote on Sat, Sep 01, 2001 at 18:43 +0300: > > The permissions are important, too, imagine a world-writeable > > ~/.ssh or a not world-readble ~/public_html. > > but this is easily achived with --archive option. > as I understand it, the issue is when restoring from backups, > and given that that's a root task, I see no problems with it. Yep, that's it. root task on both sides! > when you backup with rsync, use -a to preserve ownership and > rights, recreate links BTW, I get often errors when rsync tries to create symlinks: file already exists... oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. -- To unsubscribe, e-mail: suse-security-unsubscribe(a)suse.com For additional commands, e-mail: suse-security-help(a)suse.com

1 0

AW: [suse-security] rsync and automatics backups over ssh
by Reckhard, Tobias 03 Sep '01

03 Sep '01

> i am thinking for using rsync over ssh. > but i have a problem, the sys ask me for writting the ssh password. > there is any method using rsync and ssh for sending the password whitout > writte it? my plan is to use rsync over ssh in a cron. > I use public key authentication with a null passphrase for the private key on the client machine. Tobias

1 0

AW: [suse-security] ucd-snmpd default configuration
by Reckhard, Tobias 03 Sep '01

03 Sep '01

> SNMP is not only read but write typically. Community strings are often > easy > to guess, easier to sniff (cleartext). I suggest _heavilly_ firewalling > snmp > and maybe using ssh port forwarding or ipsec to encrypt it. > SSH won't help, as it can only perform port forwarding of TCP ports, AFAIK, while SNMP uses UDP only. I suggest a physically separate LAN or IPSec for SNMP (and syslog, BTW). And you should configure your SNMP server as tightly as possible. Make snmpwalk show only what it needs to. Cheers Tobias

1 0

ucd-snmpd default configuration
by Steffen Dettmer 02 Sep '01

02 Sep '01

Hi, I played around with MRTG which worked out-of-the-box. I just started rcsnmpd on the hosts and adjusted the firewalls to allow UDP:161 for the "monitor" host. Now the hosts run snmpd without configuration (at least it looks that there is no configuration file). I just started snmpd. Now I want to hear some statement about the risks. Since SNMP is very powerful, I fear that I opened some security leaks. OK, the firewalls are restrictive but I could sleep better if I could be sure that the default config garantes "read-only" accesses only. Second, snmpwalk reports really much things, but for MRTG I need the interface stats only. I looked for some example configuration files but they are complex to understand. Any sugesstions? Since I run SNMP now, I think about useing the check_snmp plugin with netsaint. I could imagine to check via snmp if i.e. the process "ypbind" is still running and so on. Is this secure? Or should I better not doing this? I would be glad if I could find anyone who uses check_snmp for more that checking snmpd itself. We could discuss this is little, but maybe this list is OT for that particular issue. I'm looking forward to any statements, thank you. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.

2 2

once again FreeS/WAN tunnel established, no data transferred
by Stefan_Walther＠gehag-dsk.de 01 Sep '01

01 Sep '01

Hi folks, I recognize a problem at my side. You meant "strange routing". Now I see what you mean. The IP's of the first GW on eth0 must be 192.168.200.1 and the IP on the eth1 of the second GW must be 192.168.100.1. Now I see my fault. The IP's on the boxes where set this way I told to you in the sentence before. By the way, I have a look at /var/log/messages and saw the message IPSec SA established and tcpdump tells me that there are UDP:500-->500 packets are going through the router (ip-proto-50). MfG. Stefan Walther stefan_walther(a)gehag-dsk.de dienst.: +4930/89786448 Funk: +49172/3943961 ----- Forwarded by Stefan Walther/GEHAG DSK GmbH on 01.09.2001 16:41 ----- >hi folks, >I have the following problem. I have an established IPSec-tunnel between 2 boxes. >I'm using SuSE7.1 and FreeS/WAN 1.91. The FreeS/WAN tells me that the tunnel is established (last message in /var/log/messages). >My configuration is the following: >1st client-----1st-FreeS/WAN-gateway----ROUTER----2nd-FreeS/WAN-gateway------2nd-client > eth0--------------eth0------eth1----eth1-eth0----eth0--------eth1------eth0 >!Every box is a linux box! >The 1st client has the following config: RedHat7.1, IP: 192.168.200.2 >The 1st FreeS/WAN-gateway config is: SuSE 7.1, kernel 2.4.7, eth0: 192.168.100.1, eth1: 172.16.100.1, IP-forwarding without masquerading >The Router has the following config: SuSE7.1, kernel 2.4.7, eth1: 172.16.100.2, eth0 10.16.100.2, IP-forwarding without masquerading >The 2nd FreeS/WAN-gateway config is: SuSE7.1, kernel 2.4.7, eth0: 10.16.100.1, eth1: 192.168.200.1, IP-forwarding without masquerading >The 2nd client has the following config: Windows2000, eth (seems to be a littlebit stupid): 192.168.100.2 >Every netmask is 255.255.255.0; >If i start ipsec via, ipsec start at the shell, no error (exept the IPv6-bind error) occured. >Before starting IPSec the routes, the the clients can pinging each other are set by hand. FreeS/WAN sets the routes to the ipsec0 interface. >After starting you cannot ping anymore from the 1st client to the 2nd client ans the other way around. Does anybody know a solution for this problem??? >THX MfG. Stefan Walther stefan_walther(a)gehag-dsk.de dienst.: +4930/89786448 Funk: +49172/3943961

1 0