Date: Thu, 25 Mar 1999 23:36:43 -0500 From: "Jim Flowers" <jflowers@ezo.net> To: <freebsd-security@freebsd.org> Subject: Fw: Skip configuration Message-ID: <002101be7742$400997f0$23b197ce@ezo.net>
next in thread | raw e-mail | index | archive | help
----- Original Message -----
From: Jim Flowers <jflowers@ezo.net>
To: Jean M. Vandette <vandj@securenet.net>
Sent: Thursday, March 25, 1999 11:35 PM
Subject: Re: Skip configuration
> Easier to analyze with info on both ends but I infer that you have:
>
> =============10.10.10.0/24======ethernet
> |
> [mtl] #.#.#.# KeyID 6b9d...
> |
> {Internet}
> |
> [tor] 209.167.132.39 KeyID c79f...
> |
> =============10.10.11.0/24======ethernet
>
> Most of your setup looks OK. I would also add the skiphosts to your ACLs
on
> both ends:
>
> On mtl:
>
> skiphost -a 209.167.132.39 -k DES-EDE-K3 -t DES-CBC -m MD5 -s 8 -r 8 -R
> 0xc79...
>
> On tor:
>
> skiphost -a #.#.#.# -k DES-EDE-K3 -t DES-CBC -m MD5 -s 8 -r 8 -R 0x6b9d...
>
> If you only have one key for each skiphost, it is in slot 0 and you don't
> need to include the sender KeyID. It is very important, however, that the
> keys on both ends have the same length and that they are generated with
both
> skiphosts having the correct time and date and timezone set first.
>
> I also recommend using `tcpdump proto 57 or host skiphost.address to see
> what is happening (may require rebuilding kernel with bpfilter).
>
> Here is my general procedure:
>
> On skiphost A
>
> 1. Set timezone with `/stand/sysinstall`.
> 2. Set time/date with `ntpdate isp.ntp.server`.
> 3. Delete all local keys with `skiplocal rm slot`.
> 4. Make one new key with length M using `skiplocal keygen -m M`.
> 5. Generate script with `skiplocal export > add_A`.
> 6. Copy for a template with `cp add_A add_A_net`.
> 7. Edit add_A_net to put in the network and netmask and identify the
> tunnel
> Original: skiphost -a skip.host.B.address ...
> Edited: skiphost -a sub.net.B.address -M sub.net.B.netmask -A
> skip.host.B.address ...
> 8. ftp add_A and add_A_net to skiphost B.
> 9. `skiphost -a default`
> 10. `skiphost -a sub.net.A.address -M sub.net.A.netmask`
> 11. `sh add_B`
> 12. `sh add_B_net`
> 13. `skipif -s`
> 14. `skipd_restart`
>
> On skiphost B
>
> 1. Set timezone with `/stand/sysinstall`.
> 2. Set time/date with `ntpdate isp.ntp.server`.
> 3. Delete all local keys with `skiplocal rm slot`.
> 4. Make one new key with length M (SAME AS ON A) using `skiplocal
> keygen -m M`.
> 5. Generate script with `skiplocal export > add_B`.
> 6. Copy for a template with `cp add_B add_B_net`.
> 7. Edit add_B_net to put in the network and netmask and identify the
> tunnel
> Original: skiphost -a skip.host.A.address ...
> Edited: skiphost -a sub.net.A.address -M sub.net.A.netmask -A
> skip.host.A.address ...
> 8. ftp add_B and add_B_net to skiphost A.
> 9. `skiphost -a default`
> 10. `skiphost -a sub.net.B.address -M sub.net.B.netmask`
> 11. `sh add_A`
> 12. `sh add_A_net`
> 13. `skipif -s`
> 14. `skipd_restart`
>
> The reason for saving it all before turning it on is so that you can have
> someone at the far end just boot the machine when it doesn't work and it
> will come up OK. Once you're confident that you're through with debugging
> you can save it with SKIP turned on.
>
> I also find it convenient to telnet to an intermediate device and from
there
> to the distant skiphost so that my telnet session will not be interrupted
by
> an erroneous entry.
>
> Now just issue `skiphost -o on` for the distant skiphost and then the
local
> skiphost and you should be up and tunneling.
>
> If it still doesn't work it could be that some intermediate isp is not
> forwarding your packets in one direction or the other because they have
> non-routable addresses as the source address (might be an indication of an
> attacker). Use the -f flag in the most recent ports to specify the
address
> of the local skiphost as the source. Something like:
>
> skiphost -a 10.10.11.0 -M 255.255.255.0 -A 209.167.132.39 -k DES-EDE-K3 -t
> DES-CBC -m MD5 -s 8 -r 8 -R 0xc79f... -f #.#.#.#
>
> This could well be the cause given that you can communicate skiphost to
> skiphost OK. The only place I have run into this, however, is Taiwan and
on
> my TWC RoadRunner cable system at home.
>
> Finally, do remember that the hosts on the network have to know how to get
> back to the skiphost in order to respond so you should be using routed or
> gated or have them configured with static routes for each distant network
or
> a default route pointing back to the skiphost. If you have them all
> pointing at some other machine then it should know to route responses back
> to the skiphost.
>
> That pretty well covers the lot. I would say that more than 70% of the
> problems that I have encountered relate to routing problems, not SKIP
> problems.
>
> Good luck.
>
> Jim
>
> ----- Original Message -----
> From: Jean M. Vandette <vandj@securenet.net>
> To: <jflowers@ezo.net>
> Sent: Thursday, March 25, 1999 9:16 PM
> Subject: Skip configuration
>
>
> > Greetings....
> >
> > I was given you name by Mike Smith (a good friend of mine) at FreeBSD or
> > CDROM.com whichever name you prefer as the person to talk to about
setting
> up
> > skipd for a VPN. I got skip running from one end to the other for
> pinging.
> > however the hidden private networks do not seem to see each other.
>
> > mtl# skiphost
> > fxp0: access control enabled, only authorized SKIP hosts can connect
> > default: cleartext
> > 10.10.11.*: SKIP params:
> > IP mode: tunneling
> > Tunnel address: tor
> > Kij alg: DES-EDE-K3
> > Crypt alg: DES-CBC
> > MAC alg: MD5
> > Receiver NSID: MD5 (DH Pub.Value)
> > Receiver key id: 0xc79fa41f17a16bec2e9fabedd23f6a55
> > Sender NSID: MD5 (DH Pub.Value)
> > Sender key id: 0x6b9da71fe7cc8ca40c01c8e4b7be05af
> > mtl# ping 10.10.11.1
> > PING 10.10.11.1 (10.10.11.1): 56 data bytes
> > Mar 25 19:02:37 mtl skipd: Calculating Shared secret for
> > c79fa41f17a16bec2e9fabedd23f6a55
> > Mar 25 19:02:37 mtl skipd: Done
> > ^C
> > --- 10.10.11.1 ping statistics ---
> > 8 packets transmitted, 0 packets received, 100% packet loss
>
> > The machine in tor is set the same only in reverse of course. Gateway
> > forwarding is set
> > on and as you can see when I ping the other machine, the packets seem to
> be
> > lost.
> >
> > Can you give me some pointers as to what could be wrong.
> >
> > Regards
> >
> > Jean M. Vandette
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?002101be7742$400997f0$23b197ce>