Hello Jim and the list,

Few things seem to be obscure for me (comments between lines) :

> -----Message d'origine-----
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] la part de Erich Titl
> Envoyé : samedi 5 juin 2004 14:21
> À : Jim Walters; [EMAIL PROTECTED]
> Objet : Re: [leaf-user] trying to get ipsec VPN working
>
...SNIP...

> >#
> ># Shorewall 1.4 - /etc/shorewall/tunnels
> >#
> ># TYPE                  ZONE    GATEWAY         GATEWAY
> >#                                               ZONE
> >ipsec                   net     10.0.0.3
> >#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

You can enter 0.0.0.0/0 during tests.
This only "like a filer" to avoid anybody connecting you.
More restriction with the exact IPSec partner after your tests will be
ok.

> ># defaults for subsequent connection descriptions
> >conn vpn_jim
> >         # How persistent to be in (re)keying negotiations
> (0 means very).
> >         keyingtries=0
> >         # RSA authentication with keys from DNS.
> >         authby=secret
> >         left=10.0.0.4
> >         leftsubnet=192.168.1.0/24
> >         right=10.0.0.3
> >         rightsubnet=192.168.0.0/24
> >         auto=add
>
You have described higher "interfaces=%defaultroute" but you are
describing the left IP address (and forgetting the leftnexthop). I could
be better and easyer, in your case, to enter :
                left=%defaultroute
This avoid to enter left and leftnexthop statements which are picked
automaticaly.

> One of the gateways should have auto=start

You can left auto=add if you don't want to start this tunnel at IPSec
starting.
Not a problem. As soon you send any packet to 192.168.0.0/24, as soon
the tunnel will be launched automaticaly.

Why do you use 192.168.0.0/24 ? It is not realy recommended but I agree
that this subnet work.

> ><contents of ipsec.secrets>
> ># This file holds shared secrets or RSA private keys for inter-Pluto
> ># authentication.  See ipsec_pluto(8) manpage, and HTML
> documentation.
> >
> ># RSA private key for this host, authenticating it to any other host
> ># which knows the public part.  Suitable public keys, for
> ipsec.conf, DNS,
> ># or configuration of other implementations, can be
> extracted conveniently
> ># with "ipsec showhostkey".
> >#: RSA  {
> >         # -- Create your own RSA key with "ipsec rsasigkey"
> >#       }
> ># do not change the indenting of that "}"
> >
> >10.0.0.4 %any : PSK "jwalters"
>
> I never got %any to work

I use it, but in the reverse sense as :
%any 10.0.0.4 : PSK "jwalters"

I hope that this is 10.0.0.4 side ;-)
This can work, but use a longer preshared passphrase.

Be carefull :
preshared passphrase seems to not work at all behind NAT routers !
I have this problem behind a french ISP named "Free.fr" and his last
"freebox", which is a PPP modem/converter including a SIP gateway for
telephone exchange. Free seems to connect directly his subscribers in
his 192.168.0.0/16 local network before to attribute them a public IP
address. I have checked this funny configuration this week for the first
time, and, of course, IPSec doesn't work at all !
Check if this is not the same problem with your own ISP, or do IPSec
with certificates.

Good Luck.

Best Regards,
Francois BERGERET,
France.



-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Reply via email to