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):
>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
* 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
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).
-- 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.