[Users] where can I find the patch from Tom Hiugh

From: Emilio Hoxha (emilio.hoxha_at_colubris.com)
Date: Mon Oct 21 2002 - 17:40:59 CEST

Next message: users-admin_at_lists.freeswan.org: "*****SPAM***** [Users] ÐÂÍøChinaDNSÓòÃû×¨ÌâÃâ·ÑÅàÑµÑûÇëº¯"
Previous message: Andre Speelmans: "Re: [Users] Kernel-module mismatch version (ipsec.o wascompiled for kernel version 2.4.18-i686)"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

-----BEGIN PGP SIGNED MESSAGE-----

Hello list

I'm trying to compile freeswan in redhat 8.0 but as another guy (sorry
dont remember tha name..) here in the list figured out, it fails.
I was told that there is a patch from Tom..

Thanks for any info regarding this

- -Mili
- -----Original Message-----
From: users-request_at_lists.freeswan.org
[mailto:users-request_at_lists.freeswan.org]
Sent: Wednesday, October 16, 2002 5:10 AM
To: users_at_lists.freeswan.org
Subject: Users digest, Vol 1 #695 - 35 msgs

Send Users mailing list submissions to
users_at_lists.freeswan.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freeswan.org/mailman/listinfo/users
or, via email, send a message with subject or body 'help' to
users-request_at_lists.freeswan.org

You can reach the person managing the list at
users-admin_at_lists.freeswan.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Users digest..."

Today's Topics:

   1. SuSE8.0 - FreeSWAN 1.95 - Sentinel 1.3.2 on W2K (Glenn Remstedt)
   2. Question regarding Freeswan and asymetric routing (Corey Rogers)
   3. iptables and freeswan (PRINCE Jean-Francois)
   4. RE: iptables and freeswan (felippe)
   5. =?iso-8859-1?Q?Vpn_gatway_to_gateway_and_private_ntework....?=
(Stephen J. Bevan)
   6. RE: VPN client (Rogue Shoten)
   7. From subnet to subnet (=?iso-8859-1?q?Miky=20J?=)
   8. Re: RedHat 8.0 RPMs (Sam Sgro)
   9. Re: Certificate rejected (Andreas Steffen)
  10. Waiting for MR3 (Michael Martin)
  11. Re: GRE over IPSec in 5 minutes (Mike Diehl)
  12. RE: From subnet to subnet (=?iso-8859-1?q?Miky=20J?=)
  13. RE: GRE over IPSec in 5 minutes (Joe Patterson)
  14. Receive an IP address, and more! (Rosewood)
  15. From subnet to subnet (Stephen J. Bevan)
  16. (no subject) (earl_at_maskina.com)
  17. (no subject) (earl_at_maskina.com)
  18. Re: GRE over IPSec in 5 minutes (Ken Bantoft)
  19. RE: GRE over IPSec in 5 minutes (Ken Bantoft)
  20. ANNOUNCE: Super FreeS/WAN _kb8 (Ken Bantoft)
  21. Re: Receive an IP address, and more! (Ken Bantoft)
  22. about the insatllation of KLIPS (tian.xuenong%ZTE_LTD_at_zte.com.cn)
  23. RE: Receive an IP address, and more! (Rosewood)
  24. Re: about the insatllation of KLIPS (Sam Sgro)
  25. 2 dynamic ips symetric update (Thomas Will)
  26. Re: Roadwarrior with manual keying... (Arsen Drambyan)
  27. Re: VPN client (eugen.d.jeggle_at_accenture.com)
  28. SuSE8.0 - FreeSWAN 1.95 - Sentinel 1.3.2 on W2K (Glenn Remstedt)
  29. Question regarding Roadwarrior type setup (johncoltrane39_at_gmx.de)
  30. Re: SuSE8.0 - FreeSWAN 1.95 - Sentinel 1.3.2 on W2K
(mlafon_at_arkoon.net)
  31. Re: 2 dynamic ips symetric update (John A. Sullivan III)
  32. vpn && firewalls (coUnt3r_at_gmx.net)
  33. FreeS/WAN 2.00 versions of Delete SA Notification and ALGO patches
       ? (Andreas Steffen)
  34. Tunnel up/down detection (Arsen Drambyan)

- --__--__--

Message: 1
Date: Tue, 15 Oct 2002 13:10:46 +0200
From: Glenn Remstedt <glenn.remstedt_at_teklogix.se>
Reply-To: glenn.remstedt_at_teklogix.se
To: users_at_lists.freeswan.org
Subject: [Users] SuSE8.0 - FreeSWAN 1.95 - Sentinel 1.3.2 on W2K

This is a multi-part message in MIME format.
- --------------030505010500050909000803
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi list, what's going on here ?

linux:~ # ipsec auto --up vpn

104 "vpn" #8: STATE_MAIN_I1: initiate
003 "vpn" #8: ignoring Vendor ID payload
003 "vpn" #8: ignoring Vendor ID payload
003 "vpn" #8: ignoring Vendor ID payload
003 "vpn" #8: ignoring Vendor ID payload
106 "vpn" #8: STATE_MAIN_I2: sent MI2, expecting MR2
108 "vpn" #8: STATE_MAIN_I3: sent MI3, expecting MR3
003 "vpn" #8: next payload type of ISAKMP Signature Payload has an
unknown value: 211
003 "vpn" #8: malformed payload in packet
010 "vpn" #8: STATE_MAIN_I3: retransmission; will wait 20s for response
003 "vpn" #8: next payload type of ISAKMP Signature Payload has an
unknown value: 211
003 "vpn" #8: malformed payload in packet
010 "vpn" #8: STATE_MAIN_I3: retransmission; will wait 40s for response
031 "vpn" #8: max number of retransmissions (2) reached STATE_MAIN_I3.
Possible authentication failure: no acceptable response to our first
encrypted message
000 "vpn" #8: starting keying attempt 2 of an unlimited number, but
releasing whack
linux:~ #

here are my ipsec.conf;

conn %default
        type=tunnel
        #
        left=%defaultroute
        leftsubnet=194.14.14.0/255.255.255.0
        leftcert=freeswan_cert.pem
        #
        right=194.14.14.184
        rightsubnet=194.14.14.0/24
        rightcert=sentinel_cert.pem
        #
        keyexchange=ike
        ikelifetime=240m
        keylife=5h
        auth=esp
        pfs=yes
        compress=no
        authby=rsasig
        keyingtries=0
        auto=add

# sample VPN - connection
conn vpn
        # Right Security Gateway
        right=194.14.14.184
        auto=add

- --------------030505010500050909000803
Content-Type: text/plain;
name="ike.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="ike.log"

DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; New SA
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Version = 1.0, Input packet
fields = 0001 SA
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Encode packet, version = 1.0,
flags = 0x00000000
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Packet to old negotiation
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Version = 1.0, Input packet
fields = 0012 KE NONCE
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Diffie-hellman secret
g^xy[192] = 0x255af530 c2e26f68 b5cadc8f e5a3fe2c 6cb08cdd 20268fc5
04b58e0b 2422e787 d23b535e e227db67 79e5eb0c a827681f 859226ac dfc17489
f67b4b29...
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Hash algorithm = hmac-md5
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Prf key[32] = 0x3c3a00b0
7fda4d2f dd7399c5 80fd0779 b34b6d5b 09e039b0 c5f99598 886ee5f9
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Calculating SKEYID
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Output of SKEYID hash[16] =
0x38694105 92e36131 042668fb 14cb26d7
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Output of SKEYID_d hash[16] =
0x91e64f1c f153e66d f7afc151 177c6f60
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Output of SKEYID_a hash[16] =
0x572bbaa4 d63b700c 680c510b aeebf8fe
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Output SKEYID_e hash[16] =
0xde64062a cff7df5f ef0e041b ef720326
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Final encryption key[24] =
0x3ba935b2 7710f02a 4c63de2a c6f08567 be8ab4ca 8088804e
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Encode packet, version = 1.0,
flags = 0x00000000
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Packet to old negotiation
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Version = 1.0, Input packet
fields = 00cc ID CERT CR SIG
: SPD: Can not determine per-rule trusted CA root set for remote
identity der_asn1_dn(any:0,[0..144]=C=AU, ST=Some-State, O=Internet
Widgits Pty Ltd, CN=bart.kuo.fi.ssh.com,
MAILTO=glenn.remstedt_at_teklogix.se). Using only globally trusted roots.
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Output of HASH_I hash[16] =
0xd595b652 d9724446 b232b60a 37838dba
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Restart packet
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Version = 1.0, Input packet
fields = 00cc ID CERT CR SIG
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Output of HASH_R hash[16] =
0x2e67d89e 338a0043 da094558 1f2db567
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; MESSAGE: Phase 1 version =
1.0, auth_method = RSA signatures, cipher = 3des-cbc, hash = md5, prf =
hmac-md5, life = 0 kB / 14400 sec, key len = 0, group = 5
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Encode packet, version = 1.0,
flags = 0x00000001
: Phase-1 [responder] between fqdn(udp:500,[0..6]=win2000) and
der_asn1_dn(any:0,[0..144]=C=AU, ST=Some-State, O=Internet Widgits Pty
Ltd, CN=bart.kuo.fi.ssh.com, MAILTO=glenn.remstedt_at_teklogix.se) done.
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Connected
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Packet to old negotiation
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Packet to old negotiation
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Restart packet
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Version = 1.0, Input packet
fields = 00cc ID CERT CR SIG
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Connected
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; New SA
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Version = 1.0, Input packet
fields = 0001 SA
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Encode packet, version = 1.0,
flags = 0x00000000
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Packet to old negotiation
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Version = 1.0, Input packet
fields = 0012 KE NONCE
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Diffie-hellman secret
g^xy[192] = 0x3a028039 1c14602d d7a1c11c 939236fc 54468a7f 6176a3e3
0d8b0c65 9eb133d8 b9470c3e b155b273 87d4f839 f7e2b180 2bf763d8 8e6281cf
2cb6b010...
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Hash algorithm = hmac-md5
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Prf key[32] = 0x74ad3cbd
2d41cf3d 1d79b22d 718f52dc 004f10ea e91fdf2a b9da3c5f 9e516cb9
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Calculating SKEYID
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Output of SKEYID hash[16] =
0xa7461838 73142593 b7ebde0b ac30962a
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Output of SKEYID_d hash[16] =
0xd5bf53d9 e2f8a36c bda97845 ea8df8ab
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Output of SKEYID_a hash[16] =
0x724d5ae7 26d42032 334d5edd 558180a5
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Output SKEYID_e hash[16] =
0x92f16829 3b7e317b aa00cdbf 63b88b9c
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Final encryption key[24] =
0x68b0b35d c016bc19 46533ebc 98d23c54 139a062e 0b45c01b
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Encode packet, version = 1.0,
flags = 0x00000000
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Packet to old negotiation
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Version = 1.0, Input packet
fields = 00cc ID CERT CR SIG
: SPD: Can not determine per-rule trusted CA root set for remote
identity der_asn1_dn(any:0,[0..144]=C=AU, ST=Some-State, O=Internet
Widgits Pty Ltd, CN=bart.kuo.fi.ssh.com,
MAILTO=glenn.remstedt_at_teklogix.se). Using only globally trusted roots.
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Output of HASH_I hash[16] =
0xcfa8526d 587776b1 4268d4eb b8ed1aec
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Restart packet
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Version = 1.0, Input packet
fields = 00cc ID CERT CR SIG
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Output of HASH_R hash[16] =
0x0c954ce3 02b58da1 17d56385 28e7e22d
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; MESSAGE: Phase 1 version =
1.0, auth_method = RSA signatures, cipher = 3des-cbc, hash = md5, prf =
hmac-md5, life = 0 kB / 14400 sec, key len = 0, group = 5
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Encode packet, version = 1.0,
flags = 0x00000001
: Phase-1 [responder] between fqdn(udp:500,[0..6]=win2000) and
der_asn1_dn(any:0,[0..144]=C=AU, ST=Some-State, O=Internet Widgits Pty
Ltd, CN=bart.kuo.fi.ssh.com, MAILTO=glenn.remstedt_at_teklogix.se) done.
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Connected

- --------------030505010500050909000803--

- --__--__--

Message: 2
From: Corey Rogers <jrog_at_sunbeach.net>
To: users_at_lists.freeswan.org
Date: 15 Oct 2002 07:53:01 -0400
Subject: [Users] Question regarding Freeswan and asymetric routing

- --=-78d5cvrRo/4AR+BXP4Cd
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

I've been tampering with freeswan for a bit and I can successfully
tunnel to other freswan boxes as well as netscreens devices that we use
in our internal network.

However I cannot create a tunnel to other netscreen devices which exist
in our wireless cloud. The negotiations always fail on phase2. I am
curious if it is possible to tunnel to these devices in a network where
asymetric routes are employed.

Basically what I am saying is easier described in a diagram.

=3D=3D=3D=3D> 10.40.16.254 =3D=3D=3D=3D>
10.254.2.253<=3D=3D=3D=3D>10.254.2.254
10.40.16.10
<=3D=3D=3D=3D 10.40.0.10 <=3D=3D=3D=3D

FreeSWAN nexthop nexthop Netscreen
(firewall) (Wireless Radio)
(dual interface)=20

The nexthop from the netscreen uses different IPs for traffic going to
and leaving the netscreen. This occurs until it reaches the firewall at
10.254.2.254 via another interface (10.254.1.254).

(ipsec.conf)

left=3D10.254.2.253
leftnexthop=3D10.254.2.254
right=3D10.40.16.10
rightnexthop=3D10.40.16.254

Any ideas ?

I will be experimenting with adding the firewall=3Dyes command as well
and
may use multitple tunnel settings to the one netscreen using both
interfaces on the radio. However I would be grateful for any advice that
would lead me in the right direction. Afterall the shortest distance
between any 2 objects is a straightline. So would love some advice on
this.

- --=20

Never trust people who tell you all their troubles but keep from you=20
all their joys....Jewish

There's nothing remarkable about it. All one has to do is hit the=20
right keys at the right time and the instrument plays itself ....
Johann Sebastian Bach

- --=-78d5cvrRo/4AR+BXP4Cd
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA9rAGdA1zowARrmMYRAvRIAKCWNGZt//sH+psnO8uJa6Yk8axZ9ACeInNy
NdU8Gu5vVv+y4/5ylJmNmO0=
=G72D
- -----END PGP SIGNATURE-----

- --=-78d5cvrRo/4AR+BXP4Cd--

- --__--__--

Message: 3
From: "PRINCE Jean-Francois" <jfprince_at_elv.enic.fr>
To: users_at_lists.freeswan.org
Date: Tue, 15 Oct 2002 14:49:38 +0200
Subject: [Users] iptables and freeswan

Hello,

I've got some troubles with pinging my GW or my subnet when my
firewall is active. The connection is OK but not the ping. I don't
understand and I don't know the IPTABLES configuration. May be
someone could help me.

Thanks

my config

IPTABLES="/usr/sbin/iptables" # set to your
iptables location, must be set
TCP_ALLOW="22 50 51 80 443 4662 6129" # TCP ports to allow
UDP_ALLOW="500" # UDP ports to allow
INET_IFACE="eth1" # the interface your
internet's on (one only), must be set
LAN_IFACE="eth0" # the interface your
LAN's on (one only)
DENY_ALL="" # Internet hosts to
explicitly deny from accessing your system at all
DENY_HOSTWISE_TCP="" # Specific hosts to
deny access to specific TCP ports; format is "IP>PORT"
DENY_HOSTWISE_UDP="" # Specific hosts to
deny access to specific UDP ports; format is "IP>PORT"
BLACKHOLE_DROP="DROP" # What to do for the
blackholes (same options as DROP directive above)
ALLOW_ALL="" # Internet hosts to
explicitly allow full access to your system
ALLOW_HOSTWISE_TCP="" # Specific hosts
allowed access to specific TCP ports; format is "IP>PORT"
ALLOW_HOSTWISE_UDP="" # Specific hosts
allowed access to specific UDP ports; format is "IP>PORT"
TCP_FW="4662:4662>192.168.15.55 6129:6129>192.168.15.55"
# TCP port forwards, form is "SPORT:DPORT>IP"
UDP_FW="" # UDP port forwards,
form is "SPORT:DPORT>IP"
MANGLE_TOS_OPTIMIZE="TRUE" # TOS "optimizations"
on or off (TRUE/FALSE toggle)
ENABLE="Y" # Set to 'Y' when
it's configured; this is for your own saftey

PING_FLOOD="1/s" # GLOBAL limit on
ICMP echo-requests to reply to

# Outbound filters (they work, but are of limited functionality),
probably better to use a proxy here

# Below here is experimental (please report your successes/failures)
MAC_MASQ="" # MAC addresses
permitted to use masquerading, leave blank to not use
USE_SYNCOOKIES="FALSE" # TCP SynCookies on or off
(TRUE/FALSE toggle)
RP_FILTER="FALSE" # Turns rp_filter on
or off on all interfaces (TRUE/FALSE toggle)
ACCEPT_SOURCE_ROUTE="FALSE" # Turns accept_source_route on or off
on all interfaces (TRUE/FALSE toggle)
BAD_ICMP="5 9 10 15 16 17 18" # ICMP messages to
NOT allow in from internet

FILTER_CHAINS="INETIN INETOUT DMZIN DMZOUT TCPACCEPT UDPACCEPT LDROP
LREJECT TREJECT LTREJECT"
UL_FILTER_CHAINS="ULDROP ULREJECT ULTREJECT"
LOOP_IFACE="lo"

These logging chains are valid to specify in DROP= above
#Set up LDROP
echo -n "Setting up drop chains chains: "
${IPTABLES} -t filter -A LDROP -p tcp -m limit --limit ${LOG_FLOOD}
- -j LOG --log-level 6 --log-prefix "TCP Dropped "
${IPTABLES} -t filter -A LDROP -p udp -m limit --limit ${LOG_FLOOD}
- -j LOG --log-level 6 --log-prefix "UDP Dropped "
${IPTABLES} -t filter -A LDROP -p icmp -m limit --limit ${LOG_FLOOD}
- -j LOG --log-level 6 --log-prefix "ICMP Dropped "
echo -n "LDROP "

#And LREJECT too
${IPTABLES} -t filter -A LREJECT -p tcp -m limit --limit ${LOG_FLOOD}
- -j LOG --log-level 6 --log-prefix "TCP Rejected "
${IPTABLES} -t filter -A LREJECT -p udp -m limit --limit ${LOG_FLOOD}
- -j LOG --log-level 6 --log-prefix "UDP Rejected "
${IPTABLES} -t filter -A LREJECT -p icmp -m limit --limit
${LOG_FLOOD} -j LOG --log-level 6 --log-prefix "ICMP Rejected "
${IPTABLES} -t filter -A LREJECT -f -m limit --limit ${LOG_FLOOD} -j
LOG --log-level 4 --log-prefix "FRAGMENT Rejected "
${IPTABLES} -t filter -A LREJECT -j REJECT
echo -n "LREJECT "

#Don't forget TREJECT
${IPTABLES} -t filter -A TREJECT -p tcp -j REJECT --reject-with
tcp-reset
${IPTABLES} -t filter -A TREJECT -p udp -j REJECT --reject-with
icmp-port-unreachable
${IPTABLES} -t filter -A TREJECT -p icmp -j DROP
${IPTABLES} -t filter -A TREJECT -j REJECT
echo -n "TREJECT "

#And LTREJECT
${IPTABLES} -t filter -A LTREJECT -p tcp -m limit --limit
${LOG_FLOOD} -j LOG --log-level 6 --log-prefix "TCP Rejected "
${IPTABLES} -t filter -A LTREJECT -p udp -m limit --limit
${LOG_FLOOD} -j LOG --log-level 6 --log-prefix "UDP Rejected "
${IPTABLES} -t filter -A LTREJECT -p icmp -m limit --limit
${LOG_FLOOD} -j LOG --log-level 6 --log-prefix "ICMP Rejected "
${IPTABLES} -t filter -A LTREJECT -f -m limit --limit ${LOG_FLOOD} -j
LOG --log-level 4 --log-prefix "FRAGMENT Rejected "
${IPTABLES} -t filter -A LTREJECT -p tcp -j REJECT --reject-with
tcp-reset
${IPTABLES} -t filter -A LTREJECT -p udp -j REJECT --reject-with
icmp-port-unreachable
${IPTABLES} -t filter -A LTREJECT -p icmp -j DROP
${IPTABLES} -t filter -A LTREJECT -j REJECT
echo -n "LTREJECT "

#And ULOG stuff, same as above but ULOG instead of LOG
if [ ${HAVE_ULOG} = "true" ] ; then
        ${IPTABLES} -t filter -A ULDROP -p tcp -m limit --limit
${LOG_FLOOD} -j ULOG --ulog-nlgroup 1 --ulog-prefix LDROP_TCP
        ${IPTABLES} -t filter -A ULDROP -p udp -m limit --limit
${LOG_FLOOD} -j ULOG --ulog-nlgroup 1 --ulog-prefix LDROP_UDP
        ${IPTABLES} -t filter -A ULDROP -p icmp -m limit --limit
${LOG_FLOOD} -j ULOG --ulog-nlgroup 1 --ulog-prefix LDROP_ICMP
        ${IPTABLES} -t filter -A ULDROP -f -m limit --limit
${LOG_FLOOD} -j ULOG --ulog-nlgroup 1 --ulog-prefix LDROP_FRAG
        ${IPTABLES} -t filter -A ULDROP -j DROP
        echo -n "ULDROP "

        ${IPTABLES} -t filter -A ULREJECT -p tcp -m limit --limit
${LOG_FLOOD} -j ULOG --ulog-nlgroup 1 --ulog-prefix LREJECT_TCP
        ${IPTABLES} -t filter -A ULREJECT -p udp -m limit --limit
${LOG_FLOOD} -j ULOG --ulog-nlgroup 1 --ulog-prefix LREJECT_UDP
        ${IPTABLES} -t filter -A ULREJECT -p icmp -m limit --limit
${LOG_FLOOD} -j ULOG --ulog-nlgroup 1 --ulog-prefix LREJECT_UDP
        ${IPTABLES} -t filter -A ULREJECT -f -m limit --limit
${LOG_FLOOD} -j ULOG --ulog-nlgroup 1 --ulog-prefix LREJECT_FRAG
        ${IPTABLES} -t filter -A ULREJECT -j REJECT
        echo -n "LREJECT "

        ${IPTABLES} -t filter -A ULTREJECT -p tcp -m limit --limit
${LOG_FLOOD} -j ULOG --ulog-nlgroup 1 --ulog-prefix LTREJECT_TCP
        ${IPTABLES} -t filter -A ULTREJECT -p udp -m limit --limit
${LOG_FLOOD} -j ULOG --ulog-nlgroup 1 --ulog-prefix LTREJECT_UDP
        ${IPTABLES} -t filter -A ULTREJECT -p icmp -m limit --limit
${LOG_FLOOD} -j ULOG --ulog-nlgroup 1 --ulog-prefix LTREJECT_ICM
P
        ${IPTABLES} -t filter -A ULTREJECT -f -m limit --limit
${LOG_FLOOD} -j ULOG --ulog-nlgroup 1 --ulog-prefix LTREJECT_FRAG
        ${IPTABLES} -t filter -A ULTREJECT -p tcp -j REJECT
- --reject-with tcp-reset
        ${IPTABLES} -t filter -A ULTREJECT -p udp -j REJECT
- --reject-with icmp-port-unreachable
        ${IPTABLES} -t filter -A ULTREJECT -p icmp -j DROP
        ${IPTABLES} -t filter -A ULTREJECT -j REJECT
        echo -n "ULTREJECT "

# TCPACCEPT
# SYN Flood "Protection"
${IPTABLES} -t filter -A TCPACCEPT -p tcp --syn -m limit --limit
${SYN_FLOOD} -j ACCEPT
${IPTABLES} -t filter -A TCPACCEPT -p tcp --syn -m limit --limit
${LOG_FLOOD} -j LOG --log-prefix "Possible SynFlood "
${IPTABLES} -t filter -A TCPACCEPT -p tcp --syn -j ${DROP}
${IPTABLES} -t filter -A TCPACCEPT -p tcp ! --syn -j ACCEPT
# Log anything that hasn't matched yet and ${DROP} it since it isn't
TCP and shouldn't be here
${IPTABLES} -t filter -A TCPACCEPT -m limit --limit ${LOG_FLOOD} -j
LOG --log-prefix "Mismatch in TCPACCEPT "
${IPTABLES} -t filter -A TCPACCEPT -j ${DROP}
echo -n "TCPACCEPT "

#UDPACCEPT
#UDPACCEPT
${IPTABLES} -t filter -A INPUT -i $INET_IFACE -p UDP --dport 500 -m
state --state ESTABLISHED,RELATED,NEW -j ACCEPT
${IPTABLES} -t filter -A INPUT -i $INET_IFACE -p UDP -m state --state
ESTABLISHED,RELATED,NEW -j ACCEPT
${IPTABLES} -t filter -A INPUT -i $INET_IFACE -p 50 -j ACCEPT
${IPTABLES} -t filter -A INPUT -i $INET_IFACE -p 51 -j ACCEPT
${IPTABLES} -t filter -A UDPACCEPT -p udp -j ACCEPT
# Log anything not UDP and ${DROP} it since it's not supposed to be
here
${IPTABLES} -t filter -A UDPACCEPT -m limit --limit ${LOG_FLOOD} -j
LOG --log-prefix "Mismatch on UDPACCEPT "
${IPTABLES} -t filter -A UDPACCEPT -j ${DROP}

# =================================================
# ----------------Packet Mangling------------------
# =================================================

# TTL mangling
# This is probably just for the paranoid, but hey, isn't that what
# all security guys are? :)
if [ "$TTL_SAFE" != "" ] ; then
${IPTABLES} -t mangle -A PREROUTING -i ${INET_IFACE} -j TTL
- --ttl-set ${TTL_SAFE}
fi

# Type of Service mangle optimizations (the ACTIVE FTP one will only
work for uploads)
if [ "$MANGLE_TOS_OPTIMIZE" = "TRUE" ] ; then
        echo -n "Optimizing traffic: "
        ${IPTABLES} -t mangle -A OUTPUT -p tcp --dport 23 -j TOS
- --set-tos Minimize-Delay
        echo -n "telnet "
        ${IPTABLES} -t mangle -A OUTPUT -p tcp --dport 22 -j TOS
- --set-tos Minimize-Delay
        echo -n "ssh "
        ${IPTABLES} -t mangle -A OUTPUT -p tcp --dport 20 -j TOS
- --set-tos Minimize-Cost
        echo -n "ftp-data "
        ${IPTABLES} -t mangle -A OUTPUT -p tcp --dport 21 -j TOS
- --set-tos Minimize-Delay
        echo -n "ftp-control "
        ${IPTABLES} -t mangle -A OUTPUT -p udp --dport 4000:7000 -j
TOS --set-tos Minimize-Delay
        echo -n "diablo2 "
        echo
fi

# What to do on those INET chains when we hit the end
echo -n "Setting up INET policies: "
# Drop if we cant find a valid inbound rule.
${IPTABLES} -t filter -A INETIN -j ${DROP}
echo -n "INETIN:${DROP} "
# We can send what we want to the internet
${IPTABLES} -t filter -A INETOUT -j ACCEPT
echo -n "INETOUT:ACCEPT "

- --__--__--

Message: 4
From: "felippe" <felippe_at_xlsol.com>
To: "'PRINCE Jean-Francois'" <jfprince_at_elv.enic.fr>,
<users_at_lists.freeswan.org>
Subject: RE: [Users] iptables and freeswan
Date: Tue, 15 Oct 2002 10:45:46 -0300

Are you trying to ping from the freswan box? If yes, them it is more
complicated (you will need to use NAT). If not, just put this rules and
it will work:

iptables -A INPUT -p icmp -i ipsec0 -j ACCEPT
iptables -A FORWARD -p icmp -i ipsec0 -j ACCEPT
- -----Original Message-----
From: users-admin_at_lists.freeswan.org
[mailto:users-admin_at_lists.freeswan.org] On Behalf Of PRINCE
Jean-Francois
Sent: terça-feira, 15 de outubro de 2002 09:50
To: users_at_lists.freeswan.org
Subject: [Users] iptables and freeswan

Hello,

I've got some troubles with pinging my GW or my subnet when my firewall
is active. The connection is OK but not the ping. I don't understand and
I don't know the IPTABLES configuration. May be someone could help me.

Thanks

my config

PING_FLOOD="1/s" # GLOBAL limit on
ICMP echo-requests to reply to

# Outbound filters (they work, but are of limited functionality),
probably better to use a proxy here

FILTER_CHAINS="INETIN INETOUT DMZIN DMZOUT TCPACCEPT UDPACCEPT LDROP
LREJECT TREJECT LTREJECT" UL_FILTER_CHAINS="ULDROP ULREJECT ULTREJECT"
LOOP_IFACE="lo"

These logging chains are valid to specify in DROP= above
#Set up LDROP
echo -n "Setting up drop chains chains: "
${IPTABLES} -t filter -A LDROP -p tcp -m limit --limit ${LOG_FLOOD} -j
LOG --log-level 6 --log-prefix "TCP Dropped " ${IPTABLES} -t filter -A
LDROP -p udp -m limit --limit ${LOG_FLOOD} -j LOG --log-level 6
- --log-prefix "UDP Dropped " ${IPTABLES} -t filter -A LDROP -p icmp -m
limit --limit ${LOG_FLOOD} -j LOG --log-level 6 --log-prefix "ICMP
Dropped " echo -n "LDROP "

#And LREJECT too
${IPTABLES} -t filter -A LREJECT -p tcp -m limit --limit ${LOG_FLOOD} -j
LOG --log-level 6 --log-prefix "TCP Rejected " ${IPTABLES} -t filter -A
LREJECT -p udp -m limit --limit ${LOG_FLOOD} -j LOG --log-level 6
- --log-prefix "UDP Rejected " ${IPTABLES} -t filter -A LREJECT -p icmp
-m
limit --limit ${LOG_FLOOD} -j LOG --log-level 6 --log-prefix "ICMP
Rejected " ${IPTABLES} -t filter -A LREJECT -f -m limit --limit
${LOG_FLOOD} -j LOG --log-level 4 --log-prefix "FRAGMENT Rejected "
${IPTABLES} -t filter -A LREJECT -j REJECT echo -n "LREJECT "

#Don't forget TREJECT
${IPTABLES} -t filter -A TREJECT -p tcp -j REJECT --reject-with
tcp-reset ${IPTABLES} -t filter -A TREJECT -p udp -j REJECT
- --reject-with icmp-port-unreachable ${IPTABLES} -t filter -A TREJECT
-p
icmp -j DROP ${IPTABLES} -t filter -A TREJECT -j REJECT echo -n "TREJECT
"

#And LTREJECT
${IPTABLES} -t filter -A LTREJECT -p tcp -m limit --limit ${LOG_FLOOD}
- -j LOG --log-level 6 --log-prefix "TCP Rejected " ${IPTABLES} -t
filter
- -A LTREJECT -p udp -m limit --limit ${LOG_FLOOD} -j LOG --log-level 6
- --log-prefix "UDP Rejected " ${IPTABLES} -t filter -A LTREJECT -p icmp
- -m limit --limit ${LOG_FLOOD} -j LOG --log-level 6 --log-prefix "ICMP
Rejected " ${IPTABLES} -t filter -A LTREJECT -f -m limit --limit
${LOG_FLOOD} -j LOG --log-level 4 --log-prefix "FRAGMENT Rejected "
${IPTABLES} -t filter -A LTREJECT -p tcp -j REJECT --reject-with
tcp-reset ${IPTABLES} -t filter -A LTREJECT -p udp -j REJECT
- --reject-with icmp-port-unreachable ${IPTABLES} -t filter -A LTREJECT
-p
icmp -j DROP ${IPTABLES} -t filter -A LTREJECT -j REJECT echo -n
"LTREJECT "

#And ULOG stuff, same as above but ULOG instead of LOG
if [ ${HAVE_ULOG} = "true" ] ; then
        ${IPTABLES} -t filter -A ULDROP -p tcp -m limit --limit
${LOG_FLOOD} -j ULOG --ulog-nlgroup 1 --ulog-prefix LDROP_TCP
        ${IPTABLES} -t filter -A ULDROP -p udp -m limit --limit
${LOG_FLOOD} -j ULOG --ulog-nlgroup 1 --ulog-prefix LDROP_UDP
        ${IPTABLES} -t filter -A ULDROP -p icmp -m limit --limit
${LOG_FLOOD} -j ULOG --ulog-nlgroup 1 --ulog-prefix LDROP_ICMP
        ${IPTABLES} -t filter -A ULDROP -f -m limit --limit ${LOG_FLOOD}
- -j ULOG --ulog-nlgroup 1 --ulog-prefix LDROP_FRAG
        ${IPTABLES} -t filter -A ULDROP -j DROP
        echo -n "ULDROP "

        ${IPTABLES} -t filter -A ULTREJECT -p tcp -m limit --limit
${LOG_FLOOD} -j ULOG --ulog-nlgroup 1 --ulog-prefix LTREJECT_TCP
        ${IPTABLES} -t filter -A ULTREJECT -p udp -m limit --limit
${LOG_FLOOD} -j ULOG --ulog-nlgroup 1 --ulog-prefix LTREJECT_UDP
        ${IPTABLES} -t filter -A ULTREJECT -p icmp -m limit --limit
${LOG_FLOOD} -j ULOG --ulog-nlgroup 1 --ulog-prefix LTREJECT_ICM P
        ${IPTABLES} -t filter -A ULTREJECT -f -m limit --limit
${LOG_FLOOD} -j ULOG --ulog-nlgroup 1 --ulog-prefix LTREJECT_FRAG
        ${IPTABLES} -t filter -A ULTREJECT -p tcp -j REJECT
- --reject-with tcp-reset
        ${IPTABLES} -t filter -A ULTREJECT -p udp -j REJECT
- --reject-with icmp-port-unreachable
        ${IPTABLES} -t filter -A ULTREJECT -p icmp -j DROP
        ${IPTABLES} -t filter -A ULTREJECT -j REJECT
        echo -n "ULTREJECT "

# TCPACCEPT
# SYN Flood "Protection"
${IPTABLES} -t filter -A TCPACCEPT -p tcp --syn -m limit --limit
${SYN_FLOOD} -j ACCEPT ${IPTABLES} -t filter -A TCPACCEPT -p tcp --syn
- -m limit --limit ${LOG_FLOOD} -j LOG --log-prefix "Possible SynFlood "
${IPTABLES} -t filter -A TCPACCEPT -p tcp --syn -j ${DROP} ${IPTABLES}
- -t filter -A TCPACCEPT -p tcp ! --syn -j ACCEPT # Log anything that
hasn't matched yet and ${DROP} it since it isn't TCP and shouldn't be
here ${IPTABLES} -t filter -A TCPACCEPT -m limit --limit ${LOG_FLOOD} -j
LOG --log-prefix "Mismatch in TCPACCEPT " ${IPTABLES} -t filter -A
TCPACCEPT -j ${DROP} echo -n "TCPACCEPT "

#UDPACCEPT
#UDPACCEPT
${IPTABLES} -t filter -A INPUT -i $INET_IFACE -p UDP --dport 500 -m
state --state ESTABLISHED,RELATED,NEW -j ACCEPT
${IPTABLES} -t filter -A INPUT -i $INET_IFACE -p UDP -m state --state
ESTABLISHED,RELATED,NEW -j ACCEPT ${IPTABLES} -t filter -A INPUT -i
$INET_IFACE -p 50 -j ACCEPT ${IPTABLES} -t filter -A INPUT -i
$INET_IFACE -p 51 -j ACCEPT ${IPTABLES} -t filter -A UDPACCEPT -p udp -j
ACCEPT # Log anything not UDP and ${DROP} it since it's not supposed to
be here ${IPTABLES} -t filter -A UDPACCEPT -m limit --limit ${LOG_FLOOD}
- -j LOG --log-prefix "Mismatch on UDPACCEPT " ${IPTABLES} -t filter -A
UDPACCEPT -j ${DROP}

# =================================================
# ----------------Packet Mangling------------------
# =================================================

# Type of Service mangle optimizations (the ACTIVE FTP one will only
work for uploads) if [ "$MANGLE_TOS_OPTIMIZE" = "TRUE" ] ; then
        echo -n "Optimizing traffic: "
        ${IPTABLES} -t mangle -A OUTPUT -p tcp --dport 23 -j TOS
- --set-tos Minimize-Delay
        echo -n "telnet "
        ${IPTABLES} -t mangle -A OUTPUT -p tcp --dport 22 -j TOS
- --set-tos Minimize-Delay
        echo -n "ssh "
        ${IPTABLES} -t mangle -A OUTPUT -p tcp --dport 20 -j TOS
- --set-tos Minimize-Cost
        echo -n "ftp-data "
        ${IPTABLES} -t mangle -A OUTPUT -p tcp --dport 21 -j TOS
- --set-tos Minimize-Delay
        echo -n "ftp-control "
        ${IPTABLES} -t mangle -A OUTPUT -p udp --dport 4000:7000 -j TOS
- --set-tos Minimize-Delay
        echo -n "diablo2 "
        echo
fi

_______________________________________________
Users mailing list
Users_at_lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users

- --__--__--

Message: 5
From: "Stephen J. Bevan" <stephen_at_dino.dnsalias.com>
Date: Tue, 15 Oct 2002 08:42:02 -0700
To: "=?iso-8859-1?Q?desync?=" <desync_at_libero.it>
Cc: "=?iso-8859-1?Q?users?=" <users_at_lists.freeswan.org>
Subject: [Users]
=?iso-8859-1?Q?Vpn_gatway_to_gateway_and_private_ntework....?=

desync writes:
> Hi, i enstablish a vpn in tunnel mode with two gateways: if i ping
> the external ip like 194.66.33.xx all the traffic pass in ipsec0 and
> it's correct but if i try to ping the internal ip like 192.168.0.1
and
> 192.168.1.1 id don't work ? It is normal ?

Since you didn't include your ipsec.conf on both sides then it is
not clear exactly what you did and did not set up. My *guess* is that
you successfully created a gateway<->gateway tunnel but have not also
defined a subnet<->subnet tunnel to cover the 192.168.0.1 addresses as
described in
http://www.freeswan.org/freeswan_trees/freeswan-1.98b/doc/quickstart.htm
l#gate.VPN

If you have done that then the next thing do check would be that
rp_filter
is set to 0 on your external interface, your gateways are forwarding
and that your firewall isn't blocking the packets.

- --__--__--

Message: 6
From: "Rogue Shoten" <shoten_at_rogueshoten.com>
To: "'Norbert Wegener'" <nw_at_sbs.de>, <users_at_lists.freeswan.org>
Subject: RE: [Users] VPN client
Date: Tue, 15 Oct 2002 12:44:27 -0400

SafeNet makes one, and there's another one by Funk software called
AdmitOne. In addition, there's one that's meant for wireless use by
Movian.

> -----Original Message-----
> From: users-admin_at_lists.freeswan.org
> [mailto:users-admin_at_lists.freeswan.org] On Behalf Of Norbert Wegener
> Sent: Tuesday, October 15, 2002 6:44 AM
> To: users_at_lists.freeswan.org
> Subject: [Users] VPN client
>
>
> Hello,
> some of our customers want to connect to a freeswan gateway using MS
> Pocket PC 2002 as roadwarrior client.
> We use certificates for authentication.
> Does anyone know a (commercial) client for such a system?
>
> Thanks for an answer.
>
> Norbert
>
>
> --
> Norbert Wegener Phone:(49)2012661379 Fax:(49)2012661377
> SBS Essen,Germany Mail: nw_at_sbs.de Mailfax:(49)2018165521379
> CA Cert: http://w4.siemens.de/de2/flash/digital_id/digital_id.html
>

- --__--__--

Message: 7
Date: Tue, 15 Oct 2002 18:55:47 +0200 (CEST)
From: =?iso-8859-1?q?Miky=20J?= <mikydeb_at_yahoo.fr>
To: users_at_lists.freeswan.org
Subject: [Users] From subnet to subnet

- --0-1420257687-1034700947=:36674
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi List,

I know the question have already been asked but i didn't find my answer
even searching in the mailling list archives.

I want to to that

lan1(192.168.1.0/24)<-->(192.168.1.254)FW1(x.y.z.1)<---->(x.y.z.2)R<----
------------->Internet<------------>R(a.b.c.2)<------>(a.b.c.1)FW2(192.1
68.2.254)<----->lan2(192.168.2.0/24)

The two FW are doing masquerading and encryption.

When i want to ping from a machine in lan1 to a machine in lan2, it
doesn't work. Nothing appears with a tcpdump -i ipsec0

If i ping from a machine in lan1 to the external interface or FW2
(a.b.c.1) it does work and with iptraf i can see some p50 packets.

On FW2 my nat rules are

iptables -t nat -A PREROUTING -p udp -s $internet -i ppp0 --dport 500 -j
DNAT --to $externalfw2
iptables -t nat -A PREROUTING -p 50 -s $internet -i ppp0 -j DNAT --to
$externalfw2

I told both FW to accept all the packets in the filter table to avoid
adding these problems.

Does anyone have an idea why it doesn't work ?

Do i have to write specific rules in the nat tables ? Are mine correct ?

Why the protocol is called 50 ? Because the ones i knew before where not
called with numbers (tcp, udp, icmp). Ok i know these ones are not
located on the same osi layer.

Thanx for help, i hope i'll be able to resolve that problem

- ---------------------------------
Yahoo! Mail -- Une adresse @yahoo.fr gratuite et en français !

- --0-1420257687-1034700947=:36674
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<P>Hi List,</P>
<P>I know the question have already been asked but i didn't find my
answer even searching in the mailling list archives.</P>
<P>I want to to that</P>
<P><FONT
face=Verdana>lan1(192.168.1.0/24)<-->(192.168.1.254)FW1(x.y.z.1)&l
t;---->(x.y.z.2)R<----------------->Internet<------------&gt
;R(a.b.c.2)<------>(a.b.c.1)FW2(192.168.2.254)<----->lan2(19
2.168.2.0/24)</FONT></P>
<P><FONT face=Verdana>The two FW are doing masquerading and
encryption.</FONT></P>
<P>When i want to ping from a machine in lan1 to a machine in lan2, it
doesn't work. Nothing appears with a tcpdump -i ipsec0 </P>
<P>If i ping from a machine in lan1 to the external interface or FW2
(<FONT face=Verdana>a.b.c.1) it does work and with iptraf i can see some
p50 packets.</FONT></P>
<P><FONT face=Verdana>On FW2 my nat rules are</FONT></P>
<P>iptables -t nat -A PREROUTING -p udp -s $internet -i ppp0 --dport 500
-j DNAT --to $externalfw2<BR>iptables -t nat -A PREROUTING -p 50 -s
$internet -i ppp0 -j DNAT --to $externalfw2<BR></P>
<P><FONT face=Verdana>I told both FW to accept all the packets in the
filter table to avoid adding these problems.</FONT></P>
<P><FONT face=Verdana>Does anyone have an idea why it doesn't work
?</FONT></P>
<P><FONT face=Verdana>Do i have to write specific rules in the nat
tables ? Are mine correct ?</FONT></P>
<P><FONT face=Verdana>Why the protocol is called 50 ? Because the ones i
knew before where not called with numbers (tcp, udp, icmp). Ok i know
these ones are not located on the same osi layer.</FONT></P>
<P><FONT face=Verdana>Thanx for help, i hope i'll be able to resolve
that problem</FONT></P>
<P><BR></P><p><br><hr size=1><a href="http://fr.mail.yahoo.com">Yahoo!
Mail</a> -- Une adresse @yahoo.fr gratuite et en français !<br>
- --0-1420257687-1034700947=:36674--

- --__--__--

Message: 8
Date: Tue, 15 Oct 2002 13:39:02 -0400 (EDT)
From: Sam Sgro <sam_at_freeswan.org>
To: Gustav Foseid <gustavf-freeswan_at_initio.no>
cc: <users_at_lists.freeswan.org>
Subject: Re: [Users] RedHat 8.0 RPMs

- -----BEGIN PGP SIGNED MESSAGE-----

On Tue, 15 Oct 2002, Gustav Foseid wrote:

> > > It's being work on as we speak... (see the design@ ML for
details).
> > > There's a number of issues with building on RedHat 8.0, which are
detailed
> > > there (See posts by Sam Sgro) so I won't repeat.
> >
> > If everything goes according to plan, I'll have something for the
> > list to try out by Monday (latest).
>
> Do you have a update on this?

Yes; I forgot about the Thanksgiving long weekend here in Canada. :) A
meeting today which should resolve the matter; with any luck, RPMs
should be
available tonight or tomorrow.

- - --
Sam Sgro
sam_at_freeswan.org

- -----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
Comment: For the matching public key, finger the Reply-To: address.

iQCVAwUBPaxSuEOSC4btEQUtAQFLTgP+PCjFH/zV0wG2T3eF8e0LjRu9FMyue8Kn
8O0DGlsHp7rZOHy5+KCqAMCrm7BHC6WSBgusGIwMcM3Fs1yP54n/UERVmyShBAkH
3Dpw3X9putIlswv60TaiCN44YbNizahXivs5v0pD8mb4TZjZzMF4rnVsk8k8BtK4
IJ5BKyoEW3w=
=ac8N
- -----END PGP SIGNATURE-----

- --__--__--

Message: 9
Date: Tue, 15 Oct 2002 20:20:50 +0200
From: Andreas Steffen <andreas.steffen_at_strongsec.net>
Organization: strongSec GmbH
To: =?ISO-8859-1?Q?Josep_Llaurad=F3_Selvas?= <darlock_at_tinet.org>
Cc: users_at_lists.freeswan.org
Subject: Re: [Users] Certificate rejected

If you send me both the gandalf and the CA certificate
I could tell you what is wrong with them.

Since you import the gandalf peer certificate locally using

leftcert=gandalf.innovaman.pem

trust is put directly into the host certificate. The
corresponding CA certificate is therefore not required.
This is the reason that the connection is established
although the certificate received via IKE could not
be verified successfully.

Regards

Andreas

Josep Llauradó Selvas wrote:
> Hello all,
>
> I have a VPN connection between two FreeS/SWAN systems and all runs
well.
> I'm using x509 certificates using the same CA to authorize them.
>
> I have created a CA and two certificates signed by the CA, and I say
that
> the connection only can be from gandalf to r2d2 (my freeswan boxes).
The
> tunnel runs well (I hope) but I get a lot of messages of error:
>
> ------------------------------8<---------------------
> 192.168.128.1 #597: Issuer CRL not found
> 192.168.128.1 #597: Issuer CA certificate not found
> 192.168.128.1 #597: X.509 certificate rejected
> 192.168.128.1 #597: sent MR3, ISAKMP SA established
> 192.168.128.1 #598: responding to Main Mode from unknown peer
192.168.128.1
> 192.168.128.1 #598: Peer ID is ID_DER_ASN1_DN: 'C=ES, ST=Tarragona,
O=Innova Grup Empreses
> Municipals, OU=InnovaMAN, CN=r2d2.innovaman'
> ------------------------------8<---------------------
>
> When I try to use openssl -verify using one of this certificates I get
the
> next message:
> ------------------------------8<---------------------
> aragorn:/etc/ssl/INNOVA#
> openssl verify -CAfile ca.crt
> certs/gandalf.innovaman.pem: /C=ES/ST=Tarragona/L=Reus/O=Innova Grup
> Empreses Municipals/OU=Innova Autoritat Certificadora/CN=Innova
Autoritat
> Certificadora/Email=certadmin_at_innovaman
> error 2 at 1 depth lookup:unable to get issuer certificate
> ------------------------------8<---------------------
> It seems that I have a problem with the certificates, but what I'm
doing
> wrong? and why the connection is stablished if the certificates are
wrong?
>
> The config of the connections follow:
> ------------------------------8<---------------------
> conn %default
> keyingtries=0
> authby=rsasig
> # My side is right - r2d2
> right=192.168.128.1
> rightcert=r2d2.innovaman.pem
> rightsubnet=192.168.1.0/24
> auto=add
>
> conn innova-gaia
> left=192.168.128.2
> leftcert=gandalf.innovaman.pem
> leftsubnet=192.168.63.0/24
> auto=start
> ------------------------------8<---------------------
>
> TIA
>
> _________________________________________________________
> Josep Llauradó Selvas darlock_at_tinet.org
> Linux Registered User #153481
> The only "intuitive" interface is the nipple.
> After that, it's all learned.
> (in comp.os.linux.misc, on X interfaces.)
> _________________________________________________________
>
>
> _______________________________________________
> Users mailing list
> Users_at_lists.freeswan.org
> http://lists.freeswan.org/mailman/listinfo/users

- --
======================================================================
Andreas Steffen e-mail: andreas.steffen_at_strongsec.com
strongSec GmbH phone: +41 76 340 25 56
Alter Zürichweg 20 home: http://www.strongsec.com
CH-8952 Schlieren (Switzerland)
==========================================[strong internet security]==

- --__--__--

Message: 10
From: Michael Martin <mimartin_at_bmc.com>
To: users_at_lists.freeswan.org
Date: 15 Oct 2002 15:03:17 -0500
Subject: [Users] Waiting for MR3

Hello all-

I am trying to use 2.00pre2, kernel 2.4.19, SuSE 7.3 to connect to a
Nortel Contivity server. Negotiation proceeds through MI3, where it
hangs waiting for MR3. It appears that the Nortel box is resending
MI3 packets? I do not believe that fragmentation is a problem here,
but I guess I could be wrong. In any case, it is unclear to me how to
correct that problem with SuSE's firewall implementation. Any help
would be greatly appreciated. Note: 1.98b gives the same results.

Output from ipsec auto --up:

104 "bmcx" #1: STATE_MAIN_I1: initiate
106 "bmcx" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "bmcx" #1: STATE_MAIN_I3: sent MI3, expecting MR3
010 "bmcx" #1: STATE_MAIN_I3: retransmission; will wait 20s for response
003 "bmcx" #1: discarding duplicate packet; already STATE_MAIN_I3
010 "bmcx" #1: STATE_MAIN_I3: retransmission; will wait 40s for response
003 "bmcx" #1: discarding duplicate packet; already STATE_MAIN_I3
003 "bmcx" #1: discarding duplicate packet; already STATE_MAIN_I3
031 "bmcx" #1: max number of retransmissions (2) reached STATE_MAIN_I3.
Possible authentication failure: no acceptable response to our first
encrypted message
000 "bmcx" #1: starting keying attempt 2 of at most 2, but releasing
whack

Configuration of Nortel box is:

> Encryption:
> - ESP - Triple DES with SHA1 Integrity: Enabled
> - ESP - Triple DES with MD5 Integrity: Enabled
> - ESP - 56-bit DES with SHA1 Integrity: Disabled
> - ESP - 56-bit DES with MD5 Integrity: Disabled
> - AH - Authentication Only (HMAC-SHA1): Disabled
> - AH - Authentication Only (HMAC-MD5): Disabled
> IKE Encryption and Diffie-Hellman Group: Triple DES with Group 2
> (1024-bit prime)
> Vendor ID: Disabled
> Perfect Forward Secrecy: Disabled
> Compression: Disabled
> Rekey Timeout: 00:08:00
> Rekey Data Count: (None)
> ISAKMP Retransmission Interval: 16
> ISAKMP Retransmission Max Attempts: 4

ipsec.conf and barf output can be made available.

- --
- -------------------------------------------------------------
Michael Martin
mimartin_at_bmc.com
(713) 918-2631
- ------------------------------------------------------------

- --__--__--

Message: 11
From: Mike Diehl <mdiehl_at_dominion.dyndns.org>
To: "Ken Bantoft" <ken_at_freeswan.ca>,
"Ignat Vassilev" <Ignat.Vassilev_at_optus.com.au>
Subject: Re: [Users] GRE over IPSec in 5 minutes
Date: Tue, 15 Oct 2002 13:26:30 -0400
Cc: "'Ken Bantoft'" <ken_at_freeswan.ca>, "Daniel Grob" <dgrob_at_ee.ethz.ch>,
users_at_lists.freeswan.org

I must be missing something.

Why would you want to establish an IPSec tunnel from site to site and
then
run a GRE tunnel?

TIA.

On Monday 14 October 2002 08:53 pm, Ken Bantoft wrote:
> Well, start with your normal PSK ipsec.conf file, with only a
single
> tunnel defined (host to host) between your two gateways. Or use
> X.509, or rsasig - it doesn't matter. Just get a tunnel between
your
> two sites up, host to host.
>
> Get your SA established, and the eroute happy. In other words,
*make
> sure FreeS/WAN is working* before going any further. Otherwise,
it's
> a pain to debug.
>
> Next up, it's GRE time:
>
> $remote_ip = remote side of tunnel (what ipsec# IP is on remote
GW is)
> $local_ip = local IP address (what ipsec# IP is on is)
>
> ip tunnel add site1tosite2 mode gre remote $remote_ip local
$local_ip
> ttl 255 ip link set site1tosite2 up
> ip addr add 192.168.0.1 dev site1tosite2
> ip route add 192.168.0.2/32 dev site1tosite2
>
> Remember to reverse this on the other side... eg:
>
> ip tunnel add site1tosite2 mode gre remote $local_ip local
$remote_ip
> ttl 255 ip link set site1tosite2 up
> ip addr add 192.168.0.2 dev site1tosite2
> ip route add 192.168.0.1/32 dev site1tosite2
>
> Note: I'm using only 2 IP addresses... so it's a point to point
style
> link. Handy if you have lots of these and don't wanna waste
/24's
> each time.
>
> Make sure it works - ping the other end of the GRE tunnel. Check
> iptables rules so traffic won't be dropped. You've probably done
this
> already if you're adding this to a working FreeS/WAN setup :)
>
> Then, route whatever you want over the tunnel - eg:
>
> ip route add 172.16.0.0/16 via 192.168.0.2 dev site1tosite2
>
> Or, do something completely insane (like me) and run zebra/bgpd
on
> both ends, and let them exchange routes dynamically. Never issue
an
> "ip route [add|delete]" command again!
>
> And that's about it. The exercise of putting all of this into
custom
> _updown scripts is left to the reader :)

- --
Mike Diehl
PGP Encrypted E-mail preferred.
Public Key via: http://dominion.dyndns.org/~mdiehl/mdiehl.asc

- --__--__--

Message: 12
Date: Tue, 15 Oct 2002 22:59:39 +0200 (CEST)
From: =?iso-8859-1?q?Miky=20J?= <mikydeb_at_yahoo.fr>
Subject: RE: [Users] From subnet to subnet
To: felippe <felippe_at_xlsol.com>, users_at_lists.freeswan.org

- --0-969206638-1034715579=:36037
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Yes I did patch the kernel, i didn't mentioned but you're right to ask
the question in case of.
On my FW1 i do tcpdump -i eth0|grep ESP and i have
21:11:11.714589 mailgate.xxx.info >
hostxxx-xxx-xxx-139.in-addr.btopenworld.com:
ESP(spi=0xa27fcd92,seq=0x467)
On my FW2 i do the same and i have
21:15:03.821997 yyy.yyy.yyy.18 > xxx.xxx.xx.139:
ESP(spi=0xa27fcd92,seq=0x446)

So i assume the packets are going throught the internet in an encrypted
mode.

I have set up nat because my FW are natting packets from my LANs

It looks like this on both FW

iptables -t nat -A POSTROUTING -s $LAN -d \! 192.168.2.0/24 -o eth0 -j
SNAT --to $external_iface_fw1

iptables -t nat -A POSTROUTING -s $LAN -d \! 192.168.1.0/24 -o eth0 -j
SNAT --to $external_iface_fw2

Ok so what procedure do you think i should follow to resolve that ??
What if feel is that FW2 is not forwarding the packets to Lan2 (after
they've being sent from Lan1....FW1....Internet....FW2) because using
iptraf I don't see them going
......Ok i've just run tcpdump on FW2 to see if the packets are
forwarded and nothing seems to show up.
Any ideas ?
by the way, do i have to write prerouting rules ? I wrote these rules
iptables -t nat -A PREROUTING -p udp -s $internet -i ppp0 --dport 500 -j
DNAT --to $external_iface_fw
iptables -t nat -A PREROUTING -p 50 -s $internet -i ppp0 -j DNAT --to
$external_iface_fw

Even deleting these rules doesn't work..
Regards

felippe <felippe_at_xlsol.com> wrote:You cannot NAT ipsec packets, because
you will mess with the header. TO use NAT with freeswan you need to
patch the freeswan to ignore this kind of change on the header. I don't
see why you are trying to NAT the packets? If you can make a more
detailed description of your network I will b more then happy to help
you. Regards,Felippe Piazza. -----Original Message-----
From: users-admin_at_lists.freeswan.org
[mailto:users-admin_at_lists.freeswan.org] On Behalf Of Miky J
Sent: terça-feira, 15 de outubro de 2002 13:56
To: users_at_lists.freeswan.org
Subject: [Users] From subnet to subnet

Hi List,

I know the question have already been asked but i didn't find my answer
even searching in the mailling list archives.

I want to to that

lan1(192.168.1.0/24)<-->(192.168.1.254)FW1(x.y.z.1)<---->(x.y.z.2)R<----
------------->Internet<------------>R(a.b.c.2)<------>(a.b.c.1)FW2(192.1
68.2.254)<----->lan2(192.168.2.0/24)

The two FW are doing masquerading and encryption.

When i want to ping from a machine in lan1 to a machine in lan2, it
doesn't work. Nothing appears with a tcpdump -i ipsec0

If i ping from a machine in lan1 to the external interface or FW2
(a.b.c.1) it does work and with iptraf i can see some p50 packets.

On FW2 my nat rules are

iptables -t nat -A PREROUTING -p udp -s $internet -i ppp0 --dport 500 -j
DNAT --to $externalfw2
iptables -t nat -A PREROUTING -p 50 -s $internet -i ppp0 -j DNAT --to
$externalfw2

I told both FW to accept all the packets in the filter table to avoid
adding these problems.

Does anyone have an idea why it doesn't work ?

Do i have to write specific rules in the nat tables ? Are mine correct ?

Why the protocol is called 50 ? Because the ones i knew before where not
called with numbers (tcp, udp, icmp). Ok i know these ones are not
located on the same osi layer.

Thanx for help, i hope i'll be able to resolve that problem

- ---------------------------------
Yahoo! Mail -- Une adresse @yahoo.fr gratuite et en français !

- --0-969206638-1034715579=:36037
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<P>Yes I did patch the kernel, i didn't mentioned but you're right to
ask the question in case of.
<P>On my FW1 i do tcpdump -i eth0|grep ESP and i have
<P>21:11:11.714589 mailgate.xxx.info >
hostxxx-xxx-xxx-139.in-addr.btopenworld.com:
ESP(spi=0xa27fcd92,seq=0x467)
<P>On my FW2 i do the same and i have
<P>21:15:03.821997 yyy.yyy.yyy.18 > xxx.xxx.xx.139:
ESP(spi=0xa27fcd92,seq=0x446)</P>
<P>So i assume the packets are going throught the internet in an
encrypted mode.</P>
<P>I have set up nat because my FW are natting packets from my LANs</P>
<P>It looks like this on both FW</P>
<P>iptables -t nat -A POSTROUTING -s $LAN -d \! 192.168.2.0/24 -o eth0
-j SNAT --to $external_iface_fw1<BR></P>
<P>iptables -t nat -A POSTROUTING -s $LAN -d \! 192.168.1.0/24 -o eth0
-j SNAT --to $external_iface_fw2<BR></P>
<P>Ok so what procedure do you think i should follow to resolve that ??
<P>What if feel is that FW2 is not forwarding the packets to Lan2 (after
they've being sent from Lan1....FW1....Internet....FW2) because using
iptraf I don't see them going
<P>......Ok i've just run tcpdump on FW2 to see if the packets are
forwarded and nothing seems to show up.
<P>Any ideas ?
<P>by the way, do i have to write prerouting rules ? I wrote these rules
<P>iptables -t nat -A PREROUTING -p udp -s $internet -i ppp0 --dport 500
-j DNAT --to $external_iface_fw<BR>iptables -t nat -A PREROUTING -p 50
-s $internet -i ppp0 -j DNAT --to $external_iface_fw<BR>
<P>Even deleting these rules doesn't work..
<P>Regards
<P> 
<P> <B><I>felippe <felippe_at_xlsol.com></I></B> wrote:
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT:
#1010ff 2px solid">
<META content="MSHTML 5.00.3315.2870" name=GENERATOR>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=602163019-15102002>You cannot NAT ipsec packets, because you will
mess with the header.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=602163019-15102002></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=602163019-15102002>TO use NAT with freeswan you need to patch the
freeswan to ignore this kind of change on the
header.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=602163019-15102002></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=602163019-15102002>I don't see why you are trying to NAT the
packets?</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=602163019-15102002></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=602163019-15102002>If you can make a more detailed description of
your network I will b more then happy to help you.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=602163019-15102002></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=602163019-15102002>Regards,</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=602163019-15102002>Felippe Piazza.</SPAN></FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=602163019-15102002></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=602163019-15102002></SPAN></FONT> </DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT
face=Tahoma size=2>-----Original Message-----<BR><B>From:</B>
users-admin_at_lists.freeswan.org [mailto:users-admin_at_lists.freeswan.org]
<B>On Behalf Of </B>Miky J<BR><B>Sent:</B> terça-feira, 15 de outubro de
2002 13:56<BR><B>To:</B> users_at_lists.freeswan.org<BR><B>Subject:</B>
[Users] From subnet to subnet<BR><BR></FONT></DIV>
<P>Hi List,</P>
<P>I know the question have already been asked but i didn't find my
answer even searching in the mailling list archives.</P>
<P>I want to to that</P>
<P><FONT
face=Verdana>lan1(192.168.1.0/24)<-->(192.168.1.254)FW1(x.y.z.1)&l
t;---->(x.y.z.2)R<----------------->Internet<------------&gt
;R(a.b.c.2)<------>(a.b.c.1)FW2(192.168.2.254)<----->lan2(19
2.168.2.0/24)</FONT></P>
<P><FONT face=Verdana>The two FW are doing masquerading and
encryption.</FONT></P>
<P>When i want to ping from a machine in lan1 to a machine in lan2, it
doesn't work. Nothing appears with a tcpdump -i ipsec0 </P>
<P>If i ping from a machine in lan1 to the external interface or FW2
(<FONT face=Verdana>a.b.c.1) it does work and with iptraf i can see some
p50 packets.</FONT></P>
<P><FONT face=Verdana>On FW2 my nat rules are</FONT></P>
<P>iptables -t nat -A PREROUTING -p udp -s $internet -i ppp0 --dport 500
-j DNAT --to $externalfw2<BR>iptables -t nat -A PREROUTING -p 50 -s
$internet -i ppp0 -j DNAT --to $externalfw2<BR></P>
<P><FONT face=Verdana>I told both FW to accept all the packets in the
filter table to avoid adding these problems.</FONT></P>
<P><FONT face=Verdana>Does anyone have an idea why it doesn't work
?</FONT></P>
<P><FONT face=Verdana>Do i have to write specific rules in the nat
tables ? Are mine correct ?</FONT></P>
<P><FONT face=Verdana>Why the protocol is called 50 ? Because the ones i
knew before where not called with numbers (tcp, udp, icmp). Ok i know
these ones are not located on the same osi layer.</FONT></P>
<P><FONT face=Verdana>Thanx for help, i hope i'll be able to resolve
that problem</FONT></P>
<P><BR></P>
<P><BR>
<HR SIZE=1>
<A href="http://fr.mail.yahoo.com/">Yahoo! Mail</A> -- Une adresse
@yahoo.fr gratuite et en français
!<BR></BLOCKQUOTE></BLOCKQUOTE><p><br><hr size=1><a
href="http://fr.mail.yahoo.com">Yahoo! Mail</a> -- Une adresse @yahoo.fr
gratuite et en français !<br>
- --0-969206638-1034715579=:36037--

- --__--__--

Message: 13
From: "Joe Patterson" <jpatterson_at_asgardgroup.com>
To: "Mike Diehl" <mdiehl_at_dominion.dyndns.org>
Cc: <users_at_lists.freeswan.org>
Subject: RE: [Users] GRE over IPSec in 5 minutes
Date: Tue, 15 Oct 2002 18:14:00 -0400

Several reasons. The ones that come to mind are:

1) Simplified config. If you have gateway A and gateway B, and behind A
there are N networks and behind B there are M networks, then you will
need
to define N*M connections with straight ipsec. If you use a gre tunnel,
then you will only need to define one connection, build one tunnel, and
then
add M routes on A and N routes on B. With reasonably large networks, a
linear increase in complexity with network size is *significantly*
easier to
manage than an exponential increase in complexity with network size.
Once N
and M get to be above 10 or so, it can start to get painful.

2) Non-IP protocols. Say, for instance, you've got a nice IPX network
at
two sites with internet connections. You *could* buy a leased line
between
the two for all IPX traffic, but that would be expensive. You *could*
tunnel it all in the clear, but that would be insecure. You *could*
write
your own IPX-over-IP-with-spiffy-encryption protocol, but that would be
difficult. Or, you could use an ipsec encrypted gre tunnel, and
everything
would (theoretically) work.

3) fault-tolerant routing. There's very little built in to the ipsec
protocols to either detect when a remote peer is no longer responding,
or to
find a better way to get to the networks that were previously reachable
through that dead peer. gre tunnels, when combined with standard
routing
protocols, make it easier to do this.

On that note, I have done the above (ipsec+gre+ospf/eigrp) extensively
on
cisco boxes. However, as much as I have been saying that it's a cool
thing
to do, I have just today finished setting up my first combination of
freeswan/ipsec+gre+zebra/ospf. I know that Ken has done the same thing
with
zebra/bgp, and there have been some questions about how this sort of
thing
is done, so I wanted to share some of my experiences/gotchas.

First, my biggest moment of "d'oh!", make sure your firewall rules allow
ospf traffic on your gre interfaces. :)
Second, zebra looks a lot like cisco, but acts somewhat differently.
There
are three things that need to be done in ospfd.conf to make this work:
1) for each tunnel interface, do:
        interface {tunnel-name}
         ip ospf network non-broadcast
because zebra doesn't seem to like listening for multicast messages on
virtual interfaces (which sucks). A tunnel interface *should* be a
point-to-point. but it doesn't seem to work that way.
2) because of 1, you need to define neighbors with statements like:
        router ospf
         neighbor {tunnel ip address of remote peer}
3) for some incredibly wierd reason, normal network statements like one
would use for other interfaces don't work. network statements for gre
(or
actually any point-to-point) interfaces have to be the ip address of the
local tunnel interface and have to be /32, like:
        router ospf
         network 192.168.1.1/32 area 0
even if the tunnel is 192.168.1.1/30 and you would expect a statement
like
"network 192.168.1.0/30 area 0" or even "network 192.168.0.0/16 area 0"
to
work, it won't work, zebra will not activate ospf on the interface, and
nothing will happen. Which is *really* frustrating.

- -Joe

> -----Original Message-----
> From: users-admin_at_lists.freeswan.org
> [mailto:users-admin_at_lists.freeswan.org]On Behalf Of Mike Diehl
> Sent: Tuesday, October 15, 2002 1:27 PM
> To: Ken Bantoft; Ignat Vassilev
> Cc: 'Ken Bantoft'; Daniel Grob; users_at_lists.freeswan.org
> Subject: Re: [Users] GRE over IPSec in 5 minutes
>
>
> I must be missing something.
>
> Why would you want to establish an IPSec tunnel from site to site
> and then
> run a GRE tunnel?
>
> TIA.
>
> On Monday 14 October 2002 08:53 pm, Ken Bantoft wrote:
> > Well, start with your normal PSK ipsec.conf file, with
> only a single
> > tunnel defined (host to host) between your two gateways. Or
use
> > X.509, or rsasig - it doesn't matter. Just get a tunnel
> between your
> > two sites up, host to host.
> >
> > Get your SA established, and the eroute happy. In other
> words, *make
> > sure FreeS/WAN is working* before going any further.
> Otherwise, it's
> > a pain to debug.
> >
> > Next up, it's GRE time:
> >
> > $remote_ip = remote side of tunnel (what ipsec# IP is on
> remote GW is)
> > $local_ip = local IP address (what ipsec# IP is on is)
> >
> > ip tunnel add site1tosite2 mode gre remote $remote_ip
> local $local_ip
> > ttl 255 ip link set site1tosite2 up
> > ip addr add 192.168.0.1 dev site1tosite2
> > ip route add 192.168.0.2/32 dev site1tosite2
> >
> > Remember to reverse this on the other side... eg:
> >
> > ip tunnel add site1tosite2 mode gre remote $local_ip local
> $remote_ip
> > ttl 255 ip link set site1tosite2 up
> > ip addr add 192.168.0.2 dev site1tosite2
> > ip route add 192.168.0.1/32 dev site1tosite2
> >
> > Note: I'm using only 2 IP addresses... so it's a point to
> point style
> > link. Handy if you have lots of these and don't wanna waste
/24's
> > each time.
> >
> > Make sure it works - ping the other end of the GRE tunnel.
Check
> > iptables rules so traffic won't be dropped. You've
> probably done this
> > already if you're adding this to a working FreeS/WAN setup :)
> >
> > Then, route whatever you want over the tunnel - eg:
> >
> > ip route add 172.16.0.0/16 via 192.168.0.2 dev site1tosite2
> >
> > Or, do something completely insane (like me) and run zebra/bgpd
on
> > both ends, and let them exchange routes dynamically.
> Never issue an
> > "ip route [add|delete]" command again!
> >
> > And that's about it. The exercise of putting all of this
> into custom
> > _updown scripts is left to the reader :)
>
> --
> Mike Diehl
> PGP Encrypted E-mail preferred.
> Public Key via: http://dominion.dyndns.org/~mdiehl/mdiehl.asc
>
> _______________________________________________
> Users mailing list
> Users_at_lists.freeswan.org
> http://lists.freeswan.org/mailman/listinfo/users
>
>

- --__--__--

Message: 14
From: "Rosewood" <rosewood_at_gmx.de>
To: <users_at_lists.freeswan.org>
Date: Tue, 15 Oct 2002 18:05:23 -0500
Subject: [Users] Receive an IP address, and more!

Well, the network has changed a little bit since I first setup the
network, and now a few clients need to have an IP address. For right
now, I just want them to be specified manually (which I can do in SSH
Sent), so I don't need DHCP.

Is there a certain patch I need for this? Currently I have super
freeswan 1.98b version 3 I believe (cant remember which build I have).
Do I need to do anything special when I have everything already up and
running?

I noticed that SSH Sent is no long available... That sucks. Are there
any more free IPSec clients similar to SSH Sent (don't want to use the
built in VPN stuff)?

- --__--__--

Message: 15
From: "Stephen J. Bevan" <stephen_at_dino.dnsalias.com>
Date: Tue, 15 Oct 2002 16:42:04 -0700
To: =?iso-8859-1?q?Miky=20J?= <mikydeb_at_yahoo.fr>
Cc: users_at_lists.freeswan.org
Subject: [Users] From subnet to subnet

Miky J writes:
> I know the question have already been asked but i didn't find my
> answer even searching in the mailling list archives.
[snip]
> The two FW are doing masquerading and encryption.
>
> When i want to ping from a machine in lan1 to a machine in lan2, it
> doesn't work. Nothing appears with a tcpdump -i ipsec0
>
> If i ping from a machine in lan1 to the external interface or FW2
> (a.b.c.1) it does work and with iptraf i can see some p50 packets.

It would be helpful if you posted at least your ipsec.conf since
without it nobody other than you knows what connections you actually
asked to be created.

> On FW2 my nat rules are
>
> iptables -t nat -A PREROUTING -p udp -s $internet -i ppp0 --dport 500
-j DNAT --to $externalfw2
> iptables -t nat -A PREROUTING -p 50 -s $internet -i ppp0 -j DNAT --to
$externalfw2

There should be no need to NAT ESP packets since they will be coming
from your public address (a.b.c.1).

> Why the protocol is called 50?

Because 50 is its assigned number for ESP. Look in /etc/protocols
where you'll see it listed (probably as ipv6-crypt) along with all the
other protocols such as tcp (6), udp (17) and icmp (1).

- --__--__--

Message: 16
Date: Thu, 12 Sep 2002 07:43:11 -0700
From: earl_at_maskina.com
Subject: [Users] (no subject)

Hi,

If anyone has any clues I could really use some help on this.

I am unable to establish a VPN from either Windows 2000 or Windows XP
roadwarrior clients.

I don't seem to get any errors on the gateway side.

The only error I have to go on is "IKE authentication credentials are
unacceptable" on the Windows side (oakley.log).

This error is known when trying to use Windows 2000 pre SP2 (see MS
Knowledgebase), but I am using Win2K SP2/SP3 and WinXP

I already have a running FreeSwan/Checkpoint VPN based on shared
secrets.

I stripped all legal IP addresses and replaced with xxx.xxx.xxx.xxx ,
also replaced the FQDN with XX XX XX XX XX

My setup is:

Redhat 7.3 (kernel 2.4.18.5)

IPtables 1.2.5

FreeSwan 1.98b

x509 patch 0.9.14

OpenSSL 0.9.6b

Here is my ipsec.conf on the FreeSwan side

conn intranet-roadwarrior
leftsubnet=172.18.18.0/24
also=kerberos-roadwarrior

conn MYFIREWALL-roadwarrior
        leftrsasigkey=%cert
        rightrsasigkey=%cert
        right=%any
        rightsubnet=0/0
        left=xxx.xxx.xxx.xxx
EDITED
        leftcert=kerberos.pem
        auto=add
        pfs=yes

Here is an example from the FreeSwan log

Sep 10 14:36:16 kerberos pluto[28693]: "intranet-roadwarrior"[1]
xxx.xxx.xxx.xxx #2745: starting keying attempt 992 of an unlimited
number
Sep 10 14:36:16 kerberos pluto[28693]: "intranet-roadwarrior"[1]
xxx.xxx.xxx.xxx #2751: initiating Main Mode to replace #2745
Sep 10 14:36:24 kerberos pluto[28693]: "intranet-roadwarrior"[1]
xxx.xxx.xxx.xxx #2746: max number of retransmissions (20) reached
STATE_MAIN_I1. No acceptable response to our first IKE message
Sep 10 14:36:24 kerberos pluto[28693]: "intranet-roadwarrior"[1]
xxx.xxx.xxx.xxx #2746: starting keying attempt 653 of an unlimited
number
Sep 10 14:36:24 kerberos pluto[28693]: "intranet-roadwarrior"[1]
xxx.xxx.xxx.xxx #2752: initiating Main Mode to replace #2746
Sep 10 14:36:43 kerberos pluto[28693]: "intranet-roadwarrior"[1]
xxx.xxx.xxx.xxx #2748: max number of retransmissions (20) reached
STATE_MAIN_I1. No acceptable response to our first IKE message
Sep 10 14:36:43 kerberos pluto[28693]: "intranet-roadwarrior"[1]
xxx.xxx.xxx.xxx #2748: starting keying attempt 971 of an unlimited
number
Sep 10 14:36:43 kerberos pluto[28693]: "intranet-roadwarrior"[1]
xxx.xxx.xxx.xxx #2753: initiating Main Mode to replace #2748

Here is an example from the Windows oakley log

9-09: 02:16:51:875:380 0x0 0x0
9-09: 02:16:51:875:380 ProcessFailure: sa:000D3218 centry:00000000
status:35e9
9-09: 02:16:51:875:380 Not creating notify.
9-09: 02:17:15:749:380
9-09: 02:17:15:749:380 Receive: (get) SA = 0x00000000 from
xxx.xxx.xxx.xxx EDITED
9-09: 02:17:15:749:380 ISAKMP Header: (V1.0), len = 176
9-09: 02:17:15:749:380 I-COOKIE ba7ba795aa904e21
9-09: 02:17:15:749:380 R-COOKIE 0000000000000000
9-09: 02:17:15:749:380 exchange: Oakley Main Mode
9-09: 02:17:15:749:380 flags: 0
9-09: 02:17:15:749:380 next payload: SA
9-09: 02:17:15:749:380 message ID: 00000000
9-09: 02:17:15:749:380 Filter to match: Src xxx.xxx.xxx.xxx Dst
192.168.1.34 EDITED
9-09: 02:17:15:749:380 MM PolicyName: 9
9-09: 02:17:15:749:380 MMPolicy dwFlags 2 SoftSAExpireTime 28800
9-09: 02:17:15:749:380 MMOffer[0] LifetimeSec 28800 QMLimit 1 DHGroup 2
9-09: 02:17:15:749:380 MMOffer[0] Encrypt: Triple DES CBC Hash: SHA
9-09: 02:17:15:749:380 MMOffer[1] LifetimeSec 28800 QMLimit 1 DHGroup 2
9-09: 02:17:15:749:380 MMOffer[1] Encrypt: Triple DES CBC Hash: MD5
9-09: 02:17:15:749:380 MMOffer[2] LifetimeSec 28800 QMLimit 1 DHGroup 1
9-09: 02:17:15:749:380 MMOffer[2] Encrypt: DES CBC Hash: SHA
9-09: 02:17:15:749:380 MMOffer[3] LifetimeSec 28800 QMLimit 1 DHGroup 1
9-09: 02:17:15:749:380 MMOffer[3] Encrypt: DES CBC Hash: MD5
9-09: 02:17:15:749:380 Auth[0]:RSA Sig C=XX, S=XX, L=XX, O=XX, OU=XX,
CN=XX, E=XX EDITED
9-09: 02:17:15:749:380 Responding with new SA 109328
9-09: 02:17:15:749:380 processing payload SA
9-09: 02:17:15:749:380 Received Phase 1 Transform 0
9-09: 02:17:15:749:380 Life type in Seconds
9-09: 02:17:15:749:380 Life duration of 3600
9-09: 02:17:15:749:380 Encryption Alg Triple DES CBC(5)
9-09: 02:17:15:749:380 Hash Alg MD5(1)
9-09: 02:17:15:749:380 Auth Method RSA Signature with
Certificates(3)
9-09: 02:17:15:749:380 Oakley Group 5
9-09: 02:17:15:749:380 Received Phase 1 Transform 1
9-09: 02:17:15:749:380 Life type in Seconds
9-09: 02:17:15:749:380 Life duration of 3600
9-09: 02:17:15:749:380 Encryption Alg Triple DES CBC(5)
9-09: 02:17:15:749:380 Hash Alg SHA(2)
9-09: 02:17:15:749:380 Auth Method RSA Signature with
Certificates(3)
9-09: 02:17:15:749:380 Oakley Group 5
9-09: 02:17:15:749:380 Received Phase 1 Transform 2
9-09: 02:17:15:749:380 Life type in Seconds
9-09: 02:17:15:749:380 Life duration of 3600
9-09: 02:17:15:749:380 Encryption Alg Triple DES CBC(5)
9-09: 02:17:15:749:380 Hash Alg SHA(2)
9-09: 02:17:15:749:380 Auth Method RSA Signature with
Certificates(3)
9-09: 02:17:15:749:380 Oakley Group 2
9-09: 02:17:15:749:380 Received Phase 1 Transform 3
9-09: 02:17:15:749:380 Life type in Seconds
9-09: 02:17:15:749:380 Life duration of 3600
9-09: 02:17:15:749:380 Encryption Alg Triple DES CBC(5)
9-09: 02:17:15:749:380 Hash Alg MD5(1)
9-09: 02:17:15:749:380 Auth Method RSA Signature with
Certificates(3)
9-09: 02:17:15:749:380 Oakley Group 2
9-09: 02:17:15:749:380 Phase 1 SA accepted: transform=3
9-09: 02:17:15:749:380 SA - Oakley proposal accepted
9-09: 02:17:15:749:380 constructing ISAKMP Header
9-09: 02:17:15:749:380 constructing SA (ISAKMP)
9-09: 02:17:15:749:380 Constructing Vendor
9-09: 02:17:15:749:380
9-09: 02:17:15:749:380 Sending: SA = 0x00109328 to xxx.xxx.xxx.xxx:Type
2 EDITED
9-09: 02:17:15:749:380 ISAKMP Header: (V1.0), len = 108
9-09: 02:17:15:749:380 I-COOKIE ba7ba795aa904e21
9-09: 02:17:15:749:380 R-COOKIE e0d6937880f24c52
9-09: 02:17:15:749:380 exchange: Oakley Main Mode
9-09: 02:17:15:749:380 flags: 0
9-09: 02:17:15:749:380 next payload: SA
9-09: 02:17:15:749:380 message ID: 00000000
9-09: 02:17:15:839:380
9-09: 02:17:15:839:380 Receive: (get) SA = 0x00109328 from
xxx.xxx.xxx.xxx EDITED
9-09: 02:17:15:839:380 ISAKMP Header: (V1.0), len = 180
9-09: 02:17:15:839:380 I-COOKIE ba7ba795aa904e21
9-09: 02:17:15:839:380 R-COOKIE e0d6937880f24c52
9-09: 02:17:15:839:380 exchange: Oakley Main Mode
9-09: 02:17:15:839:380 flags: 0
9-09: 02:17:15:839:380 next payload: KE
9-09: 02:17:15:839:380 message ID: 00000000
9-09: 02:17:15:839:380 processing payload KE
9-09: 02:17:15:920:380 processing payload NONCE
9-09: 02:17:15:920:380 constructing ISAKMP Header
9-09: 02:17:15:920:380 constructing KE
9-09: 02:17:15:920:380 constructing NONCE (ISAKMP)
9-09: 02:17:15:920:380 Constructing Cert Request
9-09: 02:17:15:920:380 C=XX, S=XX, L=XX, O=XX, OU=XX, CN=XX, E=XX
EDITED
9-09: 02:17:15:920:380
9-09: 02:17:15:920:380 Sending: SA = 0x00109328 to xxx.xxx.xxx.xxx:Type
2 EDITED
9-09: 02:17:15:920:380 ISAKMP Header: (V1.0), len = 333
9-09: 02:17:15:920:380 I-COOKIE ba7ba795aa904e21
9-09: 02:17:15:920:380 R-COOKIE e0d6937880f24c52
9-09: 02:17:15:920:380 exchange: Oakley Main Mode
9-09: 02:17:15:920:380 flags: 0
9-09: 02:17:15:920:380 next payload: KE
9-09: 02:17:15:920:380 message ID: 00000000
9-09: 02:17:16:170:380
9-09: 02:17:16:170:380 Receive: (get) SA = 0x00109328 from
xxx.xxx.xxx.xxx EDITED
9-09: 02:17:16:170:380 ISAKMP Header: (V1.0), len = 1660
9-09: 02:17:16:170:380 I-COOKIE ba7ba795aa904e21
9-09: 02:17:16:170:380 R-COOKIE e0d6937880f24c52
9-09: 02:17:16:170:380 exchange: Oakley Main Mode
9-09: 02:17:16:170:380 flags: 1 ( encrypted )
9-09: 02:17:16:170:380 next payload: ID
9-09: 02:17:16:170:380 message ID: 00000000
9-09: 02:17:16:170:380 processing payload ID
9-09: 02:17:16:170:380 processing payload CERT
9-09: 02:17:16:170:380 processing payload CRP
9-09: 02:17:16:170:380 processing payload SIG
9-09: 02:17:16:170:380 Verifying CertStore
9-09: 02:17:16:170:380 SubjectName: C=XX, S=XX, L=XX, O=XX, OU=XX,
CN=XX, E=XX EDITED
9-09: 02:17:16:170:380 Cert Serialnumber 01
9-09: 02:17:16:170:380 Cert SHA Thumbprint
1c138f3eb56a6f7142db2a91e2ec004e
9-09: 02:17:16:170:380 35b82b5c
9-09: 02:17:16:170:380 Trust failed. 28 0
9-09: 02:17:16:170:380 Cert Trustes. 28 0
9-09: 02:17:16:170:380 SubjectName: =XX, S=XX, L=XX, O=XX, OU=XX,
CN=XX, E=XX EDITED
9-09: 02:17:16:170:380 Cert Serialnumber 01
9-09: 02:17:16:170:380 Cert SHA Thumbprint
1c138f3eb56a6f7142db2a91e2ec004e
9-09: 02:17:16:170:380 35b82b5c
9-09: 02:17:16:170:380 Cert SHA Thumbprint
1c138f3eb56a6f7142db2a91e2ec004e
9-09: 02:17:16:170:380 35b82b5c
9-09: 02:17:16:180:380 Certificate based Identity.

Peer Subject C=XX, S=XX, L=XX, O=XX, OU=XX, CN=XX, E=XX
EDITED

Peer SHA Thumbprint 1c138f3eb56a6f7142db2a91e2ec004e35b82b5c

Peer Issuing Certificate Authority C=XX, S=XX, L=XX, O=XX, OU=XX, CN=XX,
E=XX EDITED

Root Certificate Authority

My Subject C=XX, S=XX, L=XX, O=XX, OU=XX, CN=XX, E=XX
EDITED

My SHA Thumbprint 0000000000000000000000000000000000000000

Peer IP Address: xxx.xxx.xxx.xxx
EDITED

9-09: 02:17:16:180:380 Source IP Address 192.168.1.34

Source IP Address Mask 255.255.255.255

Destination IP Address xxx.xxx.xxx.xxx
EDITED

Destination IP Address Mask 255.255.255.255

Protocol 0

Source Port 0

Destination Port 0

IKE Local Addr

IKE Peer Addr

9-09: 02:17:16:180:380 isadb_set_status sa:00109328 centry:00000000
status 35e9
9-09: 02:17:16:180:380 Key Exchange Mode (Main Mode)

9-09: 02:17:16:180:380 Source IP Address 192.168.1.34

Source IP Address Mask 255.255.255.255

Destination IP Address xxx.xxx.xxx.xxx
EDITED

Destination IP Address Mask 255.255.255.255

Protocol 0

Source Port 0

Destination Port 0

IKE Local Addr

IKE Peer Addr

9-09: 02:17:16:180:380 Certificate based Identity.

Peer Subject C=XX, S=XX, L=XX, O=XX, OU=XX, CN=XX, E=XX
EDITED

Peer SHA Thumbprint 1c138f3eb56a6f7142db2a91e2ec004e35b82b5c

Peer Issuing Certificate Authority C=XX, S=XX, L=XX, O=XX, OU=XX, CN=XX,
E=XX EDITED

Root Certificate Authority

My Subject C=XX, S=XX, L=XX, O=XX, OU=XX, CN=XX, E=XX
EDITED

My SHA Thumbprint 0000000000000000000000000000000000000000

Peer IP Address: xxx.xxx.xxx.xxx
EDITED

9-09: 02:17:16:180:380 Me

9-09: 02:17:16:180:380 IKE authentication credentials are unacceptable

9-09: 02:17:16:180:380 0x0 0x0
9-09: 02:17:16:180:380 ProcessFailure: sa:00109328 centry:00000000
status:35e9
9-09: 02:17:16:180:380 Not creating notify.
9-09: 02:17:26:174:380
9-09: 02:17:26:174:380 Receive: (get) SA = 0x00109328 from
xxx.xxx.xxx.xxx EDITED
9-09: 02:17:26:174:380 ISAKMP Header: (V1.0), len = 1660
9-09: 02:17:26:174:380 I-COOKIE ba7ba795aa904e21
9-09: 02:17:26:174:380 R-COOKIE e0d6937880f24c52
9-09: 02:17:26:174:380 exchange: Oakley Main Mode
9-09: 02:17:26:174:380 flags: 1 ( encrypted )
9-09: 02:17:26:174:380 next payload: ID
9-09: 02:17:26:174:380 message ID: 00000000
9-09: 02:17:26:174:380 Dropping SA processing because SA status set.
SA 00109328 Centry 00000000 Status 35e9
9-09: 02:17:46:173:380
9-09: 02:17:46:173:380 Receive: (get) SA = 0x00109328 from
xxx.xxx.xxx.xxx EDITED
9-09: 02:17:46:173:380 ISAKMP Header: (V1.0), len = 1660
9-09: 02:17:46:173:380 I-COOKIE ba7ba795aa904e21
9-09: 02:17:46:173:380 R-COOKIE e0d6937880f24c52
9-09: 02:17:46:173:380 exchange: Oakley Main Mode
9-09: 02:17:46:173:380 flags: 1 ( encrypted )
9-09: 02:17:46:173:380 next payload: ID
9-09: 02:17:46:173:380 message ID: 00000000
9-09: 02:17:46:173:380 Dropping SA processing because SA status set.
SA 00109328 Centry 00000000 Status 35e9

Jarl Stefansson
MASKINA
earl_at_maskina.com
GSM: +354-869-4949

- --__--__--

Message: 17
Date: Thu, 12 Sep 2002 07:42:00 -0700
From: earl_at_maskina.com
Subject: [Users] (no subject)

Hi,

If anyone has any clues I could really use some help on this.

I am unable to establish a VPN from either Windows 2000 or Windows XP
roadwarrior clients.

I don't seem to get any errors on the gateway side.

The only error I have to go on is "IKE authentication credentials are
unacceptable" on the Windows side (oakley.log).

This error is known when trying to use Windows 2000 pre SP2 (see MS
Knowledgebase), but I am using Win2K SP2/SP3 and WinXP

I already have a running FreeSwan/Checkpoint VPN based on shared
secrets.

I stripped all legal IP addresses and replaced with xxx.xxx.xxx.xxx ,
also replaced the FQDN with XX XX XX XX XX

My setup is:

Redhat 7.3 (kernel 2.4.18.5)

IPtables 1.2.5

FreeSwan 1.98b

x509 patch 0.9.14

OpenSSL 0.9.6b

Here is my ipsec.conf on the FreeSwan side

conn intranet-roadwarrior
leftsubnet=172.18.18.0/24
also=kerberos-roadwarrior

Here is an example from the FreeSwan log

Here is an example from the Windows oakley log

Peer Subject C=XX, S=XX, L=XX, O=XX, OU=XX, CN=XX, E=XX
EDITED

Peer SHA Thumbprint 1c138f3eb56a6f7142db2a91e2ec004e35b82b5c

Peer Issuing Certificate Authority C=XX, S=XX, L=XX, O=XX, OU=XX, CN=XX,
E=XX EDITED

Root Certificate Authority

My Subject C=XX, S=XX, L=XX, O=XX, OU=XX, CN=XX, E=XX
EDITED

My SHA Thumbprint 0000000000000000000000000000000000000000

Peer IP Address: xxx.xxx.xxx.xxx
EDITED

9-09: 02:17:16:180:380 Source IP Address 192.168.1.34

Source IP Address Mask 255.255.255.255

Destination IP Address xxx.xxx.xxx.xxx
EDITED

Destination IP Address Mask 255.255.255.255

Protocol 0

Source Port 0

Destination Port 0

IKE Local Addr

IKE Peer Addr

9-09: 02:17:16:180:380 isadb_set_status sa:00109328 centry:00000000
status 35e9
9-09: 02:17:16:180:380 Key Exchange Mode (Main Mode)

9-09: 02:17:16:180:380 Source IP Address 192.168.1.34

Source IP Address Mask 255.255.255.255

Destination IP Address xxx.xxx.xxx.xxx
EDITED

Destination IP Address Mask 255.255.255.255

Protocol 0

Source Port 0

Destination Port 0

IKE Local Addr

IKE Peer Addr

9-09: 02:17:16:180:380 Certificate based Identity.

Peer Subject C=XX, S=XX, L=XX, O=XX, OU=XX, CN=XX, E=XX
EDITED

Peer SHA Thumbprint 1c138f3eb56a6f7142db2a91e2ec004e35b82b5c

Peer Issuing Certificate Authority C=XX, S=XX, L=XX, O=XX, OU=XX, CN=XX,
E=XX EDITED

Root Certificate Authority

My Subject C=XX, S=XX, L=XX, O=XX, OU=XX, CN=XX, E=XX
EDITED

My SHA Thumbprint 0000000000000000000000000000000000000000

Peer IP Address: xxx.xxx.xxx.xxx
EDITED

9-09: 02:17:16:180:380 Me

9-09: 02:17:16:180:380 IKE authentication credentials are unacceptable

Jarl Stefansson
MASKINA
earl_at_maskina.com
GSM: +354-869-4949

- --__--__--

Message: 18
Date: Tue, 15 Oct 2002 22:41:25 -0400 (EDT)
From: Ken Bantoft <ken_at_freeswan.ca>
To: Mike Diehl <mdiehl_at_dominion.dyndns.org>
cc: Ignat Vassilev <Ignat.Vassilev_at_optus.com.au>,
Daniel Grob <dgrob_at_ee.ethz.ch>, <users_at_lists.freeswan.org>
Subject: Re: [Users] GRE over IPSec in 5 minutes

On Tue, 15 Oct 2002, Mike Diehl wrote:

> I must be missing something.
>
> Why would you want to establish an IPSec tunnel from site to site and
then
> run a GRE tunnel?
>
> TIA.
>

Many reasons. Quickly:

* GRE supports Broadcast + Multicast. IPSec does not.
* Use dynamic routing protocols to add/remove routes over the ipsec
interface
* Tunnel over multiple IPSec "hops" in a fully encrypted mutli-hop
network
* Because you can :)

- --
Ken Bantoft The Unoffical FreeS/WAN Site:
ken_at_freeswan.ca http://www.freeswan.ca
PGP Key: finger ken_at_bantoft.org
"We can factor the number 15 with quantum computers. We
can also factor the number 15 with a dog trained to bark
three times." -- Robert Harley, 5/12/01, Sci.crypt

- --__--__--

Message: 19
Date: Tue, 15 Oct 2002 22:48:27 -0400 (EDT)
From: Ken Bantoft <ken_at_freeswan.ca>
To: Joe Patterson <jpatterson_at_asgardgroup.com>
cc: Mike Diehl <mdiehl_at_dominion.dyndns.org>, <users_at_lists.freeswan.org>
Subject: RE: [Users] GRE over IPSec in 5 minutes

On Tue, 15 Oct 2002, Joe Patterson wrote:

> Several reasons. The ones that come to mind are:
>
> 1) Simplified config. If you have gateway A and gateway B, and behind
A
> there are N networks and behind B there are M networks, then you will
need
> to define N*M connections with straight ipsec. If you use a gre
tunnel,
> then you will only need to define one connection, build one tunnel,
and then
> add M routes on A and N routes on B. With reasonably large networks,
a
> linear increase in complexity with network size is *significantly*
easier to
> manage than an exponential increase in complexity with network size.
Once N
> and M get to be above 10 or so, it can start to get painful.

That was my primary reason for doing this. I run what I term an
Enterprise Class VPN between two datacenters. I have 2 GW's @ each
side,
running Heartbeat for IP Address takeover, ospfd for internal routing,
and
now BGP between 4 ISPs and between my own sites. My config is
nessecarily
complex, so I welcome simplicity. I also have several business partner
VPN's, run off various devices. I static-route thier remote networks on

my GW's, and ospf/bgp redistribute them to my other sides, so all
traffic
to the business partner goes through 1 link. Much simpler than giving a

partner connections to all of your sites, and much simpler to secure.

> 3) fault-tolerant routing. There's very little built in to the ipsec
> protocols to either detect when a remote peer is no longer responding,
or to
> find a better way to get to the networks that were previously
reachable
> through that dead peer. gre tunnels, when combined with standard
routing
> protocols, make it easier to do this.

Yup. My Heartbeat+FreeS/WAN combo needs dynamic routing to work
effectivly.

> On that note, I have done the above (ipsec+gre+ospf/eigrp) extensively
on
> cisco boxes. However, as much as I have been saying that it's a cool
thing
> to do, I have just today finished setting up my first combination of
> freeswan/ipsec+gre+zebra/ospf. I know that Ken has done the same
thing with
> zebra/bgp, and there have been some questions about how this sort of
thing
> is done, so I wanted to share some of my experiences/gotchas.
>
> First, my biggest moment of "d'oh!", make sure your firewall rules
allow
> ospf traffic on your gre interfaces. :)
> Second, zebra looks a lot like cisco, but acts somewhat differently.
There
> are three things that need to be done in ospfd.conf to make this work:
> 1) for each tunnel interface, do:
> interface {tunnel-name}
> ip ospf network non-broadcast
> because zebra doesn't seem to like listening for multicast messages on
> virtual interfaces (which sucks). A tunnel interface *should* be a
> point-to-point. but it doesn't seem to work that way.
> 2) because of 1, you need to define neighbors with statements like:
> router ospf
> neighbor {tunnel ip address of remote peer}
> 3) for some incredibly wierd reason, normal network statements like
one
> would use for other interfaces don't work. network statements for gre
(or
> actually any point-to-point) interfaces have to be the ip address of
the
> local tunnel interface and have to be /32, like:
> router ospf
> network 192.168.1.1/32 area 0
> even if the tunnel is 192.168.1.1/30 and you would expect a statement
like
> "network 192.168.1.0/30 area 0" or even "network 192.168.0.0/16 area
0" to
> work, it won't work, zebra will not activate ospf on the interface,
and
> nothing will happen. Which is *really* frustrating.
>
> -Joe
>

Thanks for doing this and sharing the knowledge. Pat Felt (see messages

from the past few days) has also attempted this, and got it working
today.
His experience matches yours 100%, down the network 192.168.1.1/32 area
0
config lines. I will be including both your's and his information in my

FreeS/WAN + Dynamic Routing doc (forthcoming)

- --__--__--

Message: 20
Date: Tue, 15 Oct 2002 22:38:09 -0400 (EDT)
From: Ken Bantoft <ken_at_freeswan.ca>
To: users_at_lists.freeswan.org
Subject: [Users] ANNOUNCE: Super FreeS/WAN _kb8

- -----BEGIN PGP SIGNED MESSAGE-----

Hi folks,

Sorry for another announcement so soon, but NAT-T 0.4 came out, and two
new patches came in immediatly after I released _kb7, so I figured
another
release was warranted.

Changes:

* NAT-T 0.4
* Fixes for the NULL cipher to interop with WIN2K and *BSD's KAME
* Addition of MODP768bit - insecure, but conforms to RFC 2409

As usual, it's lightly tested, however based on the lack of negative
feedback I've received, it should be stable for most folks.

Please remember to read the README.* files included, as they explain how

to use the additional functionality (ie: X.509, ALG and NAT-T)

URL: http://www.freeswan.ca/code/super-freeswan

Note: This will *NOT* compile on RedHat Linux 8.0. Starting with 8.0,
RedHat's switched up to GCC 3.2, which is far pickier about C code. It
also means anything based on 1.98b (or earlier) will not compile, and
nor
will the 2.00pre# releases. The FreeS/WAN folks have fixed this in CVS,

however it's not been backported to the 1.9x releases at the moment, and
I
don't know if they intend to do a 1.99 release (Which I'd prefer) or
wait
until 2.00 hits the FTP site. I'm working on backporting bits of it
myself, however it's slow going, and I don't have a RHL 8.0 box to test
on
at the moment. I intent that _kb9 will be a few weeks away, so I should

have it sorted out, but if anyone's got a 1.98b running on RHL 8.0, a
patch or list of changes needed would speed things up for me :)

Ken

- - --
Ken Bantoft The Unoffical FreeS/WAN Site:
ken_at_freeswan.ca http://www.freeswan.ca
PGP Key: finger ken_at_bantoft.org
"We can factor the number 15 with quantum computers. We
can also factor the number 15 with a dog trained to bark
three times." -- Robert Harley, 5/12/01, Sci.crypt

- -----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQCVAwUBPazRFFiWUusaxGxpAQGPdAP/TuX6QpVoRE9acWmDKS6WwShtc2qeDGYB
DHo3MB5PC3QRHJPfkHe4lgCNJWennY0VMwh0i/dG7w87+usanb9kWkKbVW8GYoyw
rJE5HKs2hFBv6huY1h8PZzYoG0gUZS6kZtu4uIv7+K9KHFEk56gZN85b1CfxP+rw
oPYIJgsnILo=
=apM/
- -----END PGP SIGNATURE-----

- --__--__--

Message: 21
Date: Tue, 15 Oct 2002 22:49:51 -0400 (EDT)
From: Ken Bantoft <ken_at_freeswan.ca>
To: Rosewood <rosewood_at_gmx.de>
cc: users_at_lists.freeswan.org
Subject: Re: [Users] Receive an IP address, and more!

On Tue, 15 Oct 2002, Rosewood wrote:

> Well, the network has changed a little bit since I first setup the
> network, and now a few clients need to have an IP address. For right
> now, I just want them to be specified manually (which I can do in SSH
> Sent), so I don't need DHCP.
>
> Is there a certain patch I need for this? Currently I have super
> freeswan 1.98b version 3 I believe (cant remember which build I have).
> Do I need to do anything special when I have everything already up and
> running?
>

I believe you've got everything you need. See the X.509 docs on info on

how to do this, since they provide this functionality.

> I noticed that SSH Sent is no long available... That sucks. Are there
> any more free IPSec clients similar to SSH Sent (don't want to use the
> built in VPN stuff)?
>

it's still available, it's just no longer free since it's out of beta
phase.

- --__--__--

Message: 22
To: users_at_lists.freeswan.org
From: tian.xuenong%ZTE_LTD_at_zte.com.cn
Date: Wed, 16 Oct 2002 11:39:38 +0800
Subject: [Users] about the insatllation of KLIPS

Dear Sir/Madam,

I tried to install freeswan on redhat, I had installed the
software
according to the installation guide, when I ran the command "ipsec
verify",the following message appeared,
-
------------------------------------------------------------------------
-----
Checking your system to see if IPsec got installed and started correctly
Version check and ipsec on-path [OK]
Checking for KLIPS support in kernel [FAILED]
Checking for RSA private key (/etc/ipsec.secrets) [OK]
Checking that pluto is running [FAILED]
DNS checks.
Looking for forward key for freeswan [OK]
Does the machine have at least one non-private address [OK]
-
------------------------------------------------------------------------
------
I used Linux 2.4.7-10 and freeswan-1.98b.tar.gz

the key problem was the lacking of KLIPS in kernel. I am a beginner of
linux, so I wish someone can tell me something about it .Thanks.

- --__--__--

Message: 23
From: "Rosewood" <rosewood_at_gmx.de>
To: <users_at_lists.freeswan.org>
Subject: RE: [Users] Receive an IP address, and more!
Date: Wed, 16 Oct 2002 00:15:07 -0500

Ill look into those Docs then, thanks once again

As for SSH Sent no longer being free - that's a real bummer. Are there
any free sollutions? Shit, if I could code anything, I would say a good
full featured open source ipsec implementation in windows is needed.

Hasn't SSH Sent been available for free for a VERY long time tho?

> -----Original Message-----
> From: users-admin_at_lists.freeswan.org
> [mailto:users-admin_at_lists.freeswan.org] On Behalf Of Ken Bantoft
> Sent: Tuesday, October 15, 2002 9:50 PM
> To: Rosewood
> Cc: users_at_lists.freeswan.org
> Subject: Re: [Users] Receive an IP address, and more!
>
>
>
> On Tue, 15 Oct 2002, Rosewood wrote:
>
> > Well, the network has changed a little bit since I first setup the
> > network, and now a few clients need to have an IP address.
> For right
> > now, I just want them to be specified manually (which I can
> do in SSH
> > Sent), so I don't need DHCP.
> >
> > Is there a certain patch I need for this? Currently I have super
> > freeswan 1.98b version 3 I believe (cant remember which
> build I have).
> > Do I need to do anything special when I have everything
> already up and
> > running?
> >
>
> I believe you've got everything you need. See the X.509 docs
> on info on
> how to do this, since they provide this functionality.
>
> > I noticed that SSH Sent is no long available... That sucks.
> Are there
> > any more free IPSec clients similar to SSH Sent (don't want
> to use the
> > built in VPN stuff)?
> >
>
> it's still available, it's just no longer free since it's out of beta
> phase.
>
> --
> Ken Bantoft The Unoffical FreeS/WAN Site:
> ken_at_freeswan.ca http://www.freeswan.ca
> PGP Key: finger ken_at_bantoft.org
> "We can factor the number 15 with quantum computers. We
> can also factor the number 15 with a dog trained to bark
> three times." -- Robert Harley, 5/12/01, Sci.crypt
>
> _______________________________________________
> Users mailing list
> Users_at_lists.freeswan.org
> http://lists.freeswan.org/mailman/listinfo/use> rs
>

- --__--__--

Message: 24
Date: Wed, 16 Oct 2002 02:45:01 -0400 (EDT)
From: Sam Sgro <sam_at_freeswan.org>
To: <tian.xuenong%ZTE_LTD_at_zte.com.cn>
cc: <users_at_lists.freeswan.org>
Subject: Re: [Users] about the insatllation of KLIPS

- -----BEGIN PGP SIGNED MESSAGE-----

On Wed, 16 Oct 2002 tian.xuenong%ZTE_LTD_at_zte.com.cn wrote:

> I tried to install freeswan on redhat, I had installed the
software
> according to the installation guide, when I ran the command "ipsec
> verify",the following message appeared,
>
------------------------------------------------------------------------
-----
> Checking your system to see if IPsec got installed and started
correctly
> Version check and ipsec on-path [OK]
> Checking for KLIPS support in kernel [FAILED]

Either the kernel recompile failed; you have successfully recompiled
your
kernel, but are still using the old kernel instead of the new IPSec
enabled
kernel; or you've configured IPSec as a module, but it has failed to
load.
However, there is a simpler solution for this situation:

> I used Linux 2.4.7-10 and freeswan-1.98b.tar.gz

There are RPMs available for this RedHat kernel available here:

ftp.xs4all.nl/pub/crypto/freeswan/binaries/RedHat-RPMs/2.4.7-10

Just install and follow the instructions from there.

- - --
Sam Sgro
sam_at_freeswan.org

- -----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
Comment: For the matching public key, finger the Reply-To: address.

iQCVAwUBPa0K70OSC4btEQUtAQGG2gQAxcwAjHi8lCG4KRLM1Q1YKHourdQ6LaEt
LMxMdeU5NxrISXfZqBoTVDtGBuCpyLIct1xIWHC08NvdMNTPX1zSojntHt8QWbr+
exdfJu1yqa7+UNBBuC/BcuQFs6q+dNRLFKBNMec7gLSc9YwrOU5JbVEdKIo1DQ4g
RK7ClsnqPBg=
=NJul
- -----END PGP SIGNATURE-----

- --__--__--

Message: 25
Date: Wed, 16 Oct 2002 09:49:24 +0200
From: Thomas Will <thomas.will_at_xinux.de>
To: users_at_lists.freeswan.org
Subject: [Users] 2 dynamic ips symetric update

hello

i 'm seeking a solution (example) to make a tunnel
with 2 freeswan gateways with 2 dynamic ips
i have registrated both sites on dyndns.org
conn sux-tux
      left=sux.suxer.net
      leftsubnet=192.168.1.0/24
      leftnexthop=217.5.98.35
      right=tux.suxer.net
      rightnexthop=217.5.98.34
      rightsubnet=192.168.254.0/24
      auto=add
this configuration works fine
but i must patch on every reconnect ipsec.conf
with the nexthop values
i can't use on both ends left=%defaultroute
                         right=%defaultroute
is there a solution for a symetric update of both sites
without patching ipsec.conf

regards
- --
- - thomas will -
- - xinux - networking - security - consulting - training -
- - fon 06332 44040 - fax 06332 44041 - mobil 0171 8054788 -
- - 66482 zweibruecken - etzelweg 65 - http://www.xinux.de -

- --__--__--

Message: 26
From: "Arsen Drambyan" <Arsen.Drambyan_at_epygilab.am>
To: "Ken Bantoft" <ken_at_freeswan.ca>
Cc: <users_at_lists.freeswan.org>
Subject: Re: [Users] Roadwarrior with manual keying...
Date: Wed, 16 Oct 2002 12:47:05 +0400

Thanks, Ken!

But the problem is, that when I edit such a config file, where
there is right=%any, and it uses a manual connection, I get
an error, when I try to up it...
I do:
ipsec manual --up test
And I get:
/lib/ipsec/spi --label test: Error, illegal (non-DNS-name) character in
name
converting --sa argument:tun0x100@%any

May be there is still some reason for this error?

Arsen Drambyan
Epygi Labs AM

- ----- Original Message -----
From: "Ken Bantoft" <ken_at_freeswan.ca>
To: "Arsen Drambyan" <Arsen.Drambyan_at_epygilab.am>
Cc: <users_at_lists.freeswan.org>
Sent: Wednesday, October 09, 2002 3:39 PM
Subject: Re: [Users] Roadwarrior with manual keying...

> On Wed, 9 Oct 2002, Arsen Drambyan wrote:
>
> > Hi everyone!
> >
> > Can I have a roadwarrior that uses manual keying?
> > I've tried, but did not succeed... Please tell me if it's possible,
and
how?
> > Or, is there any reason, why it's not possible?
> >
> > Thanks in advance,
> > Arsen Drambyan
> > Epygi Labs AM
> >
>
> Yes. However, every roadwarrior must use the same key - very
insecure.
> Also, you may need to set uniqueids=no in your ipsec.conf.
>
> See http://www.freeswan.ca/docs/BEFVP41/ for the head-end side config
that
> I've used in the past.
>
> --
> Ken Bantoft The Unoffical FreeS/WAN Site:
> ken_at_freeswan.ca http://www.freeswan.ca
> PGP Key: finger ken_at_bantoft.org
> "We can factor the number 15 with quantum computers. We
> can also factor the number 15 with a dog trained to bark
> three times." -- Robert Harley, 5/12/01, Sci.crypt
>
> _______________________________________________
> Users mailing list
> Users_at_lists.freeswan.org
> http://lists.freeswan.org/mailman/listinfo/users
>
>

- --__--__--

Message: 27
Subject: Re: [Users] VPN client
To: "users_at_lists.freeswan.org" <users_at_lists.freeswan.org>
From: eugen.d.jeggle_at_accenture.com
Date: Wed, 16 Oct 2002 10:15:46 +0200

Hi,

I was rather interested in this topic, but accidentally deleted the
response to this question.
Please could you guys resend it, or if someone could forward it to me.

know

pock
et

2002

has
a

buil
t
in

VPN

clie
nt

(ass

ume

PPTP
).

Rega

rds

Euge
n

Norbert Wegener <nw_at_sbs.de>

Sent by: To:
"users_at_lists.freeswan.org" <users_at_lists.freeswan.org>

users-admin_at_lists.freeswan. cc:

org Subject: [Users] VPN
client

10/15/2002 12:43 PM

Hello,
some of our customers want to connect to a freeswan gateway using MS
Pocket PC 2002 as roadwarrior client.
We use certificates for authentication.
Does anyone know a (commercial) client for such a system?

Thanks for an answer.

Norbert

- --
Norbert Wegener Phone:(49)2012661379 Fax:(49)2012661377
SBS Essen,Germany Mail: nw_at_sbs.de Mailfax:(49)2018165521379
CA Cert: http://w4.siemens.de/de2/flash/digital_id/digital_id.html

This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you have
received it in error, please notify the sender immediately and delete
the
original. Any other use of the email by you is prohibited.

- --__--__--

Message: 28
Reply-To: "Glenn Remstedt" <glenn.remstedt_at_teklogix.se>
From: "Glenn Remstedt" <glenn.remstedt_at_teklogix.se>
To: "Free/SWAN maillist" <users_at_lists.freeswan.org>
Date: Wed, 16 Oct 2002 10:10:12 +0200
Organization: Psion Teklogix AB
Subject: [Users] SuSE8.0 - FreeSWAN 1.95 - Sentinel 1.3.2 on W2K

This is a multi-part message in MIME format.

- ------=_NextPart_000_0035_01C274FC.3714B600
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

hi list, what's going on here ?

linux:~ # ipsec auto --up vpn

104 "vpn" #8: STATE_MAIN_I1: initiate
003 "vpn" #8: ignoring Vendor ID payload
003 "vpn" #8: ignoring Vendor ID payload
003 "vpn" #8: ignoring Vendor ID payload
003 "vpn" #8: ignoring Vendor ID payload
106 "vpn" #8: STATE_MAIN_I2: sent MI2, expecting MR2
108 "vpn" #8: STATE_MAIN_I3: sent MI3, expecting MR3
003 "vpn" #8: next payload type of ISAKMP Signature Payload has an
unknown value: 211
003 "vpn" #8: malformed payload in packet
010 "vpn" #8: STATE_MAIN_I3: retransmission; will wait 20s for response
003 "vpn" #8: next payload type of ISAKMP Signature Payload has an
unknown value: 211
003 "vpn" #8: malformed payload in packet
010 "vpn" #8: STATE_MAIN_I3: retransmission; will wait 40s for response
031 "vpn" #8: max number of retransmissions (2) reached STATE_MAIN_I3.

Possible authentication failure: no acceptable response to our first
encrypted message
000 "vpn" #8: starting keying attempt 2 of an unlimited number, but
releasing whack
linux:~ #

here are my ipsec.conf;

conn %default
         type=tunnel
         #
         left=%defaultroute
         leftsubnet=194.14.14.0/255.255.255.0
         leftcert=freeswan_cert.pem
         #
         right=194.14.14.184
         rightsubnet=194.14.14.0/24
         rightcert=sentinel_cert.pem
         #
         keyexchange=ike
         ikelifetime=240m
         keylife=5h
         auth=esp
         pfs=yes
         compress=no
         authby=rsasig
         keyingtries=0
         auto=add

# sample VPN - connection
conn vpn
         # Right Security Gateway
         right=194.14.14.184
         auto=add
- ------=_NextPart_000_0035_01C274FC.3714B600
Content-Type: application/octet-stream;
        name="ike.log"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
        filename="ike.log"

DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; New SA
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Version =3D 1.0, Input packet
=
fields =3D 0001 SA=20
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Encode packet, version =3D =
1.0, flags =3D 0x00000000
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Packet to old negotiation
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Version =3D 1.0, Input packet
=
fields =3D 0012 KE NONCE=20
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Diffie-hellman secret =
g^xy[192] =3D 0x255af530 c2e26f68 b5cadc8f e5a3fe2c 6cb08cdd 20268fc5 =
04b58e0b 2422e787 d23b535e e227db67 79e5eb0c a827681f 859226ac dfc17489
=
f67b4b29...
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Hash algorithm =3D hmac-md5
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Prf key[32] =3D 0x3c3a00b0 =
7fda4d2f dd7399c5 80fd0779 b34b6d5b 09e039b0 c5f99598 886ee5f9
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Calculating SKEYID
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Output of SKEYID hash[16] =3D
=
0x38694105 92e36131 042668fb 14cb26d7
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Output of SKEYID_d hash[16] =
=3D 0x91e64f1c f153e66d f7afc151 177c6f60
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Output of SKEYID_a hash[16] =
=3D 0x572bbaa4 d63b700c 680c510b aeebf8fe
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Output SKEYID_e hash[16] =3D =
0xde64062a cff7df5f ef0e041b ef720326
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Final encryption key[24] =3D =
0x3ba935b2 7710f02a 4c63de2a c6f08567 be8ab4ca 8088804e
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Encode packet, version =3D =
1.0, flags =3D 0x00000000
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Packet to old negotiation
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Version =3D 1.0, Input packet
=
fields =3D 00cc ID CERT CR SIG=20
: SPD: Can not determine per-rule trusted CA root set for remote =
identity der_asn1_dn(any:0,[0..144]=3DC=3DAU, ST=3DSome-State, =
O=3DInternet Widgits Pty Ltd, CN=3Dbart.kuo.fi.ssh.com, =
MAILTO=3Dglenn.remstedt_at_teklogix.se). Using only globally trusted =
roots.
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Output of HASH_I hash[16] =3D
=
0xd595b652 d9724446 b232b60a 37838dba
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Restart packet
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Version =3D 1.0, Input packet
=
fields =3D 00cc ID CERT CR SIG=20
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Output of HASH_R hash[16] =3D
=
0x2e67d89e 338a0043 da094558 1f2db567
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; MESSAGE: Phase 1 version =3D =
1.0, auth_method =3D RSA signatures, cipher =3D 3des-cbc, hash =3D md5,
=
prf =3D hmac-md5, life =3D 0 kB / 14400 sec, key len =3D 0, group =3D 5
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Encode packet, version =3D =
1.0, flags =3D 0x00000001
: Phase-1 [responder] between fqdn(udp:500,[0..6]=3Dwin2000) and =
der_asn1_dn(any:0,[0..144]=3DC=3DAU, ST=3DSome-State, O=3DInternet =
Widgits Pty Ltd, CN=3Dbart.kuo.fi.ssh.com, =
MAILTO=3Dglenn.remstedt_at_teklogix.se) done.
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Connected
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Packet to old negotiation
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Packet to old negotiation
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Restart packet
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Version =3D 1.0, Input packet
=
fields =3D 00cc ID CERT CR SIG=20
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b70b6b26 8c92de7e -
=
db3a7f50 2b000003 [-1] / 0x00000000 } IP; Connected
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
=
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; New SA
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
=
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Version =3D 1.0, Input packet
=
fields =3D 0001 SA=20
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
=
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Encode packet, version =3D =
1.0, flags =3D 0x00000000
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
=
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Packet to old negotiation
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
=
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Version =3D 1.0, Input packet
=
fields =3D 0012 KE NONCE=20
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
=
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Diffie-hellman secret =
g^xy[192] =3D 0x3a028039 1c14602d d7a1c11c 939236fc 54468a7f 6176a3e3 =
0d8b0c65 9eb133d8 b9470c3e b155b273 87d4f839 f7e2b180 2bf763d8 8e6281cf
=
2cb6b010...
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
=
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Hash algorithm =3D hmac-md5
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
=
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Prf key[32] =3D 0x74ad3cbd =
2d41cf3d 1d79b22d 718f52dc 004f10ea e91fdf2a b9da3c5f 9e516cb9
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
=
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Calculating SKEYID
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
=
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Output of SKEYID hash[16] =3D
=
0xa7461838 73142593 b7ebde0b ac30962a
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
=
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Output of SKEYID_d hash[16] =
=3D 0xd5bf53d9 e2f8a36c bda97845 ea8df8ab
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
=
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Output of SKEYID_a hash[16] =
=3D 0x724d5ae7 26d42032 334d5edd 558180a5
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
=
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Output SKEYID_e hash[16] =3D =
0x92f16829 3b7e317b aa00cdbf 63b88b9c
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
=
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Final encryption key[24] =3D =
0x68b0b35d c016bc19 46533ebc 98d23c54 139a062e 0b45c01b
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
=
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Encode packet, version =3D =
1.0, flags =3D 0x00000000
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
=
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Packet to old negotiation
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
=
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Version =3D 1.0, Input packet
=
fields =3D 00cc ID CERT CR SIG=20
: SPD: Can not determine per-rule trusted CA root set for remote =
identity der_asn1_dn(any:0,[0..144]=3DC=3DAU, ST=3DSome-State, =
O=3DInternet Widgits Pty Ltd, CN=3Dbart.kuo.fi.ssh.com, =
MAILTO=3Dglenn.remstedt_at_teklogix.se). Using only globally trusted =
roots.
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
=
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Output of HASH_I hash[16] =3D
=
0xcfa8526d 587776b1 4268d4eb b8ed1aec
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
=
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Restart packet
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
=
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Version =3D 1.0, Input packet
=
fields =3D 00cc ID CERT CR SIG=20
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
=
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Output of HASH_R hash[16] =3D
=
0x0c954ce3 02b58da1 17d56385 28e7e22d
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
=
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; MESSAGE: Phase 1 version =3D =
1.0, auth_method =3D RSA signatures, cipher =3D 3des-cbc, hash =3D md5,
=
prf =3D hmac-md5, life =3D 0 kB / 14400 sec, key len =3D 0, group =3D 5
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
=
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Encode packet, version =3D =
1.0, flags =3D 0x00000001
: Phase-1 [responder] between fqdn(udp:500,[0..6]=3Dwin2000) and =
der_asn1_dn(any:0,[0..144]=3DC=3DAU, ST=3DSome-State, O=3DInternet =
Widgits Pty Ltd, CN=3Dbart.kuo.fi.ssh.com, =
MAILTO=3Dglenn.remstedt_at_teklogix.se) done.
DEBUG: 0.0.0.0:500 (Responder) <-> 194.14.14.8:500 { b679cedf 087069fc -
=
1d8d4c61 fe000004 [-1] / 0x00000000 } IP; Connected

- ------=_NextPart_000_0035_01C274FC.3714B600--

- --__--__--

Message: 29
Date: Wed, 16 Oct 2002 10:56:54 +0200 (MEST)
From: johncoltrane39_at_gmx.de
To: users_at_lists.freeswan.org
Subject: [Users] Question regarding Roadwarrior type setup

Hi list,

I have a question regarding a roadwarrior type setup. I have to
establish
such a structure (for management purposes to be exact. Therefore with
static
adresses, no dialup, and only for some type of protocols (but tcp, udp
and icmp
is needed).

What are the criterias when I can/should use either transport or
tunneling
mode ? The adresses do not have to be hidden (what speaks for transport
mode),
but what other criterias should be applied against this decision ?

Hopefully anybody could shed some light over this question :-)

Thanks in advance

- --
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!

- --__--__--

Message: 30
From: mlafon_at_arkoon.net
To: "Glenn Remstedt" <glenn.remstedt_at_teklogix.se>
cc: "Free/SWAN maillist" <users_at_lists.freeswan.org>
Date: Wed, 16 Oct 2002 11:41:55 +0200
Subject: Re: [Users] SuSE8.0 - FreeSWAN 1.95 - Sentinel 1.3.2 on W2K

> 003 "vpn" #8: next payload type of ISAKMP Signature Payload has an
> unknown value: 211
> 003 "vpn" #8: malformed payload in packet

SSH Sentinel bug.

Uncheck 'Enable Network Address Translation Traversal (NAT-T)' in
Advanced properties.

- --
Math.

- --__--__--

Message: 31
Subject: Re: [Users] 2 dynamic ips symetric update
From: "John A. Sullivan III" <John.Sullivan_at_nexusmgmt.com>
To: Thomas Will <thomas.will_at_xinux.de>
Cc: users_at_lists.freeswan.org
Organization:
Date: 16 Oct 2002 06:16:09 -0400

        We're working on an integrated management console for Free
S/WAN,
iptables and some other Open Source security products right now. We've
not turned our attention to this issue but it is on the drawing board
for our next phase.
        Our initial thoughts are something like this:
        We haven't yet written a policy communication protocol like COPS
for
this console so we are using OpenSSH as sort of poor man's out-of-band
policy communication protocol to provide a poor man's registration
service. The central console is available to the world via SSH.
        The central console keeps a database of all Policy Enforcement
Devices. When a PEP boots, it writes a small file containing its
DER_ASN.1_DN id and IP address and any other information needed to
establish a tunnel, opens an SSH session with the central console
authenticated via a key and drops the file off in a safe directory.
        We are speculating that we can then run a cron job on the
console that
scans that directory. When it finds a file, it parses the information
and compares it against what it finds in the database. If it has
changed, it writes a new connection record file and scp's it to all
PEP's in the VPN (we keep all connections in a separate directory and
add them via an include statement in the ipsec.conf file), and ssh's a
command ipsec auto commands to tear down the old connections and bring
up the new ones.
        We don't know yet if it will work and hope that when we get
around to
writing a policy communication protocol, it will be much cleaner but
perhaps this will give you some ideas for now. A similar approach has
proved successful for remotely adding, deleting and changing PEP's from
a central management console. Let me know how you fare! Good luck -
John

On Wed, 2002-10-16 at 03:49, Thomas Will wrote:
> hello
>
> i 'm seeking a solution (example) to make a tunnel
> with 2 freeswan gateways with 2 dynamic ips
> i have registrated both sites on dyndns.org
> conn sux-tux
> left=sux.suxer.net
> leftsubnet=192.168.1.0/24
> leftnexthop=217.5.98.35
> right=tux.suxer.net
> rightnexthop=217.5.98.34
> rightsubnet=192.168.254.0/24
> auto=add
> this configuration works fine
> but i must patch on every reconnect ipsec.conf
> with the nexthop values
> i can't use on both ends left=%defaultroute
> right=%defaultroute
> is there a solution for a symetric update of both sites
> without patching ipsec.conf
>
> regards
> --
> - thomas will -
> - xinux - networking - security - consulting - training -
> - fon 06332 44040 - fax 06332 44041 - mobil 0171 8054788 -
> - 66482 zweibruecken - etzelweg 65 - http://www.xinux.de -
>
> _______________________________________________
> Users mailing list
> Users_at_lists.freeswan.org
> http://lists.freeswan.org/mailman/listinfo/users
- --
John A. Sullivan III
Group Technology Director
Nexus Management
+1 207-985-7880
John.Sullivan_at_nexusmgmt.com

- --__--__--

Message: 32
Date: Wed, 16 Oct 2002 12:19:52 +0200 (MEST)
From: coUnt3r_at_gmx.net
To: users_at_lists.freeswan.org
Subject: [Users] vpn && firewalls

hi all,

my little question:

which ports on a firewall must be open for vpn with x.509?

my szenario:

roadwariors(dyn.ip e.g. from a hotel)==>
==>personal_firewall on the laptop==>

==>internet==>

==>corporate firwewall (static ip)==>
==>vpn gateway(static ip)==>

==>LAN(private ip)

and the same way back to the roadwarrior...

That's quite enough open the few ports (which ports are that?),
or we must make another necessary adjustments?

TIA
Toby

- --
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!

- --__--__--

Message: 33
Date: Wed, 16 Oct 2002 12:41:26 +0200
From: Andreas Steffen <andreas.steffen_at_strongsec.net>
Organization: strongSec GmbH
To: Mathieu Lafon <mlafon_at_arkoon.net>,
JuanJo Ciarlante <jjo-ipsec_at_mendoza.gov.ar>
Cc: FreeS/WAN Users <users_at_lists.freeswan.org>
Subject: [Users] FreeS/WAN 2.00 versions of Delete SA Notification and
ALGO patches
?

Hi Mathieu and JuanJo,

I'm nearly finished with the integration of dynamic CRL fetching
via URLs into the X.509 patch. This new feature will be made available
with the upcoming version 1.1.0 of the X.509 patch for
freeswan-2.00pre2,
but will not be back-ported to freeswan-1.98b. In order to have a
fully working system containing your patches I wanted to ask you when
you will be ready to support version 2.00 of FreeS/WAN?

Kind regards

Andreas

======================================================================
Andreas Steffen e-mail: andreas.steffen_at_strongsec.com
strongSec GmbH phone: +41 76 340 25 56
Alter Zürichweg 20 home: http://www.strongsec.com
CH-8952 Schlieren (Switzerland)
==========================================[strong internet security]==

- --__--__--

Message: 34
From: "Arsen Drambyan" <Arsen.Drambyan_at_epygilab.am>
To: <users_at_lists.freeswan.org>
Date: Wed, 16 Oct 2002 15:47:05 +0400
Subject: [Users] Tunnel up/down detection

This is a multi-part message in MIME format.

- ------=_NextPart_000_003B_01C2752B.46FACBC0
Content-Type: text/plain;
charset="koi8-r"
Content-Transfer-Encoding: quoted-printable

Hi, everyone!

How can we find out if a manual connection (manually keyed one)
is established? Because, the ipsec eroute shows the tunnels,
even if there's no physical connection... and ping is not very =
suitable...

And how can we know, that a connection (both manually or automatically
keyed) went down? For automatic connections we can find it out after
any rekeying. Isn't there another way to know that?
And for manual connections...?=20

Thanks,
Arsen Drambyan
Epygi Labs AM

- ------=_NextPart_000_003B_01C2752B.46FACBC0
Content-Type: text/html;
charset="koi8-r"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dkoi8-r">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi, everyone!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>How can we find out if a manual =
connection=20
(manually keyed one)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>is established? Because, the ipsec =
eroute shows the=20
tunnels,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>even if there's no physical =
connection... and ping=20
is not very suitable...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>And how can we know, that a connection
=
(both=20
manually or automatically</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>keyed) went down? For automatic =
connections we=20
can find it out after</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>any rekeying. Isn't there another way =
<FONT=20
face=3DArial size=3D2>to know that?</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>And for manual connections...? =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Arsen Drambyan</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Epygi Labs AM</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV></BODY></HTML>

- ------=_NextPart_000_003B_01C2752B.46FACBC0--

- --__--__--

_______________________________________________
Users mailing list
Users_at_lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users

End of Users Digest

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQCVAwUBPbQtBUg0xBvjMR6rAQFuEgP/S71EueB5RZw0vlBDmuUNj2dRkkBCE9BC
ZRbBaSkkVSs62HyxcnTXp+HytWOUE5Ah8GvVaHJBUFZQhXpb6Vus4HwwiS4vqqhk
ts4GHQ8pEXkt82J1Egx55+deHKNDkDzF5LYU4qehtwpXDqdDmBk+GsdTJYGqORJt
n6a26wpoS0s=
=+E4/
-----END PGP SIGNATURE-----

_______________________________________________
Users mailing list
Users_at_lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users

Next message: users-admin_at_lists.freeswan.org: "*****SPAM***** [Users] ÐÂÍøChinaDNSÓòÃû×¨ÌâÃâ·ÑÅàÑµÑûÇëº¯"
Previous message: Andre Speelmans: "Re: [Users] Kernel-module mismatch version (ipsec.o wascompiled for kernel version 2.4.18-i686)"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

This archive was generated by hypermail 2.1.5 : Tue Oct 22 2002 - 05:20:31 CEST