[ previous ] [ next ] [ threads ]
 
 From:  "Chad R. Larson" <clarson at eldocomp dot com>
 To:  Giorgio Catena <thechain at libero dot it>, m0n0wall mailing list <m0n0wall at lists dot m0n0 dot ch>
 Subject:  Re: [m0n0wall] System requirements and CheckpointSecuremoteVPN-1
 Date:  Mon, 27 Oct 2003 19:13:00 -0700
At 01:47 PM 10/26/2003, Giorgio Catena wrote:
>Chad R. Larson wrote:
>>I am sending this through an IPsec/IKE tunnel with a Soekris net4501 on 
>>this end and a Sun E250 running Checkpoint Firewall-1 on the remote 
>>end.  The net4501's WAN port is connected to a Cox cable modem, and gets 
>>its configuration from Cox via DHCP.  No sweat. One thing to keep in 
>>mind, the m0n0wall doesn't automatically generate the firewall rules 
>>needed when you configure a VPN.  When you configure a NAT, it offers to 
>>make the firewall changes needed, but not for this (listening, 
>>Manuel?).  Without a rule that allows UDP to port 500 of your outer (WAN) 
>>IP address, the IKE negotiation will fail. Here's the relevant 
>>configuration files (addresses not real, to protect the guilty):

>Cut...
>Sorry for the second reply again.... I read the racoon conf file but it is 
>not clear to me what you did....I want to say that it seems you load a 
>sort of key for the authentication and this is something I do not have at 
>all, am I right and do I have to ask for thekey or do I have simply to 
>enable the UDP 500 port and take inspiration from that file?

Here's what I hoped you could do.
1) Use the "backup/restore" portion of the GUI to fetch your config file.
2) Edit the snippit I sent you to change the IP addresses to match your needs.
3) Paste the edited snippit into your config file.
4) Restore your configuration with the "backup/restore" function.

Perhaps that's to confusing.  Let's try another way.

First, we set up which addresses are to be involved in the tunnel.

    * Click on IPsec under VPN on the left-hand navigation bar.
    * The first box allows you to pick what addresses on your end are going 
to go be visible to the system on the other end of the tunnel.  You 
probably want "LAN subnet".
    * Next, you pick what addresses should be visible to your system from 
the other end in the "Remote subnet" field.  That should be your office's 
addresses, probably.  Note that whatever you select here has to be 
accessible by the remote gateway (next).
    * Pick the VPN endpoint at the remote end in the "Remote gateway" 
section.  You have now set up the end points for the tunnel, and what is 
called the "encryption domain", that is, the set of addresses to go through 
the tunnel rather than through the ugly old internet.

Now we teach m0n0wall how to negotiate keys.

    * Pick "main" for the Phase 1 negotiation mode.
    * Pick what your end is to be called.  I'd recommend "My IP Address".
    * Pick the method you want to encrypt the key exchange.  This must 
match whatever is being used by the other end of the tunnel.  In my example 
I sent earlier, I'm using 3DES (Triple-DES).
    * Pick a hashing method.  Again, it must match the other end.  We used 
MD5 (Message Digest version five).
    * Pick a Diffie-Hellman key group.  Yet another that must match the 
other end.  We used "2", for a 1024-bit group.
    * Pick a lifetime.  This is how long this session will be valid without 
re-negotiating the keys.  We used 86400 seconds (one day).
    * Pick a shared secret.  Each end has to agree on this one too.  You 
now have defined enough for an IKE exchange.  Each end uses the above items 
to generate/negotiate an encryption key to be used on the data traveling 
through the tunnel.  The negotiation is itself encrypted, so no one 
listening will be able to unravel the keys.  This is why there is a shared 
secret.  Keep it to yourself and whomever is running the other endpoint.

Now your end and the other end have come up with and encryption key to be 
used, so you finally have to pick the cypher to be used for the encryption.

    * You can specify ESP, or AH in "Phase 2".  AH means you will be 
authenticated as the guy on the other end (right shared secret, right 
identifier, etc.) and ESP means all that plus encrypted data.  I can't 
imagine why you wouldn't use ESP if whatever you're doing already needs a 
tunnel.
    * Pick the cyphers you are willing to offer the other end.  They will 
pick one they both agree upon.  Almost every VPN endpoint can do 3DES, 
Blowfish is generally faster to compute and will therefore put less load on 
your endpoint unless you have a hardware encryption engine.
    * Once again pick a hash.  We did MD5 again.
    * Select your PFS key group, if you're using Perfect Forward 
Secrecy.  Since you said you were using a Checkpoint firewall on the other 
end, you probably want to set that to "off".  A Cisco box would want group 5.
    * And finally, pick a lifetime.  This is how long before a new 
encryption key has to be generated.  We used 3600 seconds (one hour) in the 
previous example.

You will want to have done all this in coordination with whomever is or has 
configured the other end, as you can see.  Once you've made it this far, 
the first time you try to access an address in the encryption domain you 
set up in the first segment, your firewall should bring up the tunnel.

If you traceroute from a machine on your subnet to a machine on the remote 
subnet, you should see three hops (your firewall, the other firewall and 
the remote machine).  That's why it is called a Private Network, because it 
looks like you just bought your very own wire between the two 
locations.  It's called Virtual, because you didn't really.  Your packets 
still take the same route as before, but they get stuck inside larger 
packets at your end, and stripped out at the other end (where they are 
dropped on the remote subnet).

Ok? 

-- CONFIDENTIALITY NOTICE --

This message is intended for the sole use of the individual and entity to whom it is addressed, and
may contain information that is privileged, confidential and exempt from disclosure under applicable
law. If you are not the intended addressee, nor authorized to receive for the intended addressee,
you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or
any information contained in the message. If you have received this message in error, please
immediately advise the sender by reply email, and delete the message. Thank you.