Log into your SmallWall and click IPsec , under VPN.
Now we need to add a VPN connection, to do this click on the 
icon.
The first area is the one you use to establish what network ranges will use this IPsec tunnel.
This is the first set of fields that we need to concentrate on. Later, when testing your tunnel, you can actually fail to establish level 2 connection if this data is incorrect. I will note what to pay particular attention to as we go along.
Mode, this is a hard set option and frankly you don’t need to change it (nor can you.)
Disabled, this is a great “on / off” button if you need to disable the tunnel for what ever reason. Simply select the edit or
from the main VPN: IPsec window and click this
checkbox element, then select apply at the bottom of the page. When
you need the tunnel again, reverse the process.Interface, this is how you determine which part of your network will be the termination point (end point) for the VPN Tunnel. If you are connecting to a remote server, then WAN is your option.
Local subnet. This is where you can set which parts, hosts, or the entire LAN can be accessed from the other side of the VPN tunnel. The easiest thing to do is to set the LAN subnet as the option; this means your entire LAN will be accessible from the remote network. IMPORTANT: The other end of the tunnel has this same field, well it probably has 99% of these fields actually, make sure the other end is set exactly as you set this end. E.g. if you said “Single host” in this section and entered the IP address of that host, the other person would set that host in his “Remote Subnet” field. The same goes for you, and with that mentioned we move to the next field.
Remote Subnet. This is more than just labeling which hosts and / or host you want to access on the other network, as mentioned in item 4 it is paramount that you set this exactly like the other end’s “local subnet” section. If not, level 2 of the VPN connection will fail and traffic will not pass from one VPN segment to the other.
Description: It is a good practice to always leave notes about why you are doing something. I suggest you enter something about what this VPN tunnel is used for, or about the remote end of the tunnel to remind yourself who/what it is.
All the basic for the routing have been established. Now we move on to phase 1 of the VPN authentication process.
Okay the easy part of the VPN tunnel. The trick here, and even in phase 2, is to make sure that both VPN servers have EXACTLY THE SAME SETTINGS for all of these fields. Well okay, they will have different “My identifier” but make darn sure that they know each others names… more on that later.
Negotiation mode: This is the type of authentication security that will be used. Unless you are running on a system that is very underpowered, do not use aggressive. It is indeed faster and will insure that your VPN tunnel will rebuild itself quickly and probably won’t time out an application if the tunnel was down when the resource on the other end was requested. But it is also less secure. But the biggest reason not to use it is that it will not work with L2TP, and someone enabling L2TP later will break a tunnel configured with aggressive.
My identifier: This is the key to probably 90% of the trouble where people seem to not get the VPN tunnel up, or want to know how to do this with dynamic IP addresses, etc. Very simple, set your identifier to something that is not going to change. So if you leave it as My IP address (* This will be the IP address of the “interface” you listed in the first section. *) then make sure that IP is static and persistent. If you use a DHCP assigned address then I would suggest using domain name instead This is because domain name can be completely your own even if you do not own the domain name. Make yours idonothaveadomain.com just for fun.
-
Encryption Algorithm: 3DES is the world de facto… if you are connecting to another SmallWall, or a system that will support it, change this to Blowfish. It is a more secure and about twice as fast! Now of course, if you are trying to connect to a VPN device that only supports DES then you will need to downgrade and hope no one decrypts your key exchange. MAKE SURE BOTH VPN DEVICES ARE USING THE SAME ENCRYPTION ALGORITHM.
Note
DES and 3DES are considered broken and only offer trivial encryption.
Hash Algorithm: this is the hash used for checksum. MD5 and SHA1 are the traditional standards, but not very secure. SHA-256 or better is a much better choice. Again make sure you are using the same setting as the other end of the tunnel, and if you can use SHA1 go for it!
DH Key Group: Most systems will support at least up to 1024 bit. This is a good place to stick to, going with more will eat up more resources and less makes your tunnel less-secure.
Lifetime: This field is far more important then it appears. This lifetime, as opposed to the one in phase 2, is how long your end will wait for phase 1 to be completed. A few minutes should be fine.
Preshared Key: Contrary to some suggestions this key must be exactly the same on both VPN routers. It is case sensitive, and it does support special characters. I suggest something long. E.x. thisismykeyandnooneelsehasjustthisone@all
Okay if you managed to coordinate and get both VPN systems set the same all should be good for phase 1. We really don’t want to stop here, so let’s go right into phase 2.
Phase 2 is what builds the actual tunnel, sets the protocol to use, and sets the length of time to keep the tunnel up when there is no traffic on it.
Protocol: ESP is the de facto on what most VPN systems use as a transport protocol. I suggest leaving this as is.
Encryption algorithms: Like before in phase 1, make sure you are setting the algorithm exactly as it is set on the other VPN server. You can use several; when you do so everything you select is available for use. Honestly I like to keep things simple so I recommend only checking the one you are going to use. With SmallWall to SmallWall use Blowfish for speed and security.
Hash algorithms: again just as in phase 1 you want to make sure your selected hash matches the one on the other end. And like in step 2, don’t add things you don’t need. SHA-256 is the suggestion if you can, but MD5 and SHA1 are still available for compatibility.
PFS key group: this works exactly like it does in phase 1. I suggest using 1024 bit, the default is off.
Lifetime: This is the lifetime the negotiated keys will be valid for. Do not set this to too high of a number. E.g. more than about a day (86400) as doing so will give people more time to crack your key. Don’t be over paranoid either; there is no need to set this to 20 minutes or something like that. I use about 8 hours. (28800)
Click Save
Click Apply Changes