ScreenOS to Linux VPN Instructions
This is a legacy article that was copied over from Prolixium Dot Com. It's historical in nature and was published in 2004. Please do not rely on any part of it to be accurate anymore.
This will give you the basic steps of setting up an aggressive mode site-to-site or dial-up VPN connection to a NetScreen firewall. I was using Gentoo GNU/Linux at the time, but most of these instructions are generic, and should work for any Linux/BSD-based platform using the KAME tools.
These instructions vary slightly depending on whether you're setting up a dial-up or site-to-site VPN connection. I'll try to illustrate both examples, first the dial-up, then site-to-site.
Dial-Up VPN
A dial-up VPN has nothing to do with a phone line or a modem. Well, it can, but typically this means that your one PC is going to initiate a connection from a roaming [dynamic] IP to the remote firewall. This is the setup you want if you're on the road, or only one host wants to connect to the VPN.
Example addresses for Dial-Up VPN:
- 1.2.2.2 - public IP of the NetScreen
- 172.16.1.2 - current client address
- 192.168.10.0 - private net, at remote site
- "mkamichoff" - user
- "dialupusers" - IKE users group
- "abc123" - pre-shared key for the connection
- "sampleuser@host.com" - local IKE id
Example diagram for Dial-Up VPN:
/--------------------------\ /- -\
| Linux client | ( )
| eth0: 172.16.1.2 |-------------- Internet
\--------------------------/ ( )
\- -/
|
|
|
/----------------------------\
| NetScreen Firewall |
| ethernet1: 1.2.2.2 |
| [Untrust zone] |
| ethernet2: 192.168.10.1/24 |
| [Trust zone, irrelevant] |
\----------------------------/
|
|
|
/- -\
( )
192.168.10.0/24
Private Net
( )
\- -/
NetScreen Configuration: Dial-Up VPN
The basic steps on the NetScreen side to create the dial-up VPN consist of four steps: create the users and group for the VPN, create the IKE gateway, create the autokey IKE VPN, add policies. Since it's difficult to go over the steps needed in the web-UI, I'll outline the CLI commands that are needed.
1) Create the users and group
Here, we'll create a couple IKE users, then assign them to a group. The group here is actually optional, but most organizations have more than one individual using the VPN, so I figured I'd go over this. The first step is to create the user:
set user "mkamichoff" ike-id u-fqdn "sampleuser@host.com" share-limit 1 set user "mkamichoff" type ike set user "mkamichoff" "enable"
Now, we'll just add a group and add the user:
set user-group "dialupusers" user "mkamichoff"
2) Create the IKE gateway
Creating the IKE gateway consists of specifying the user group, setting aggressive mode, setting the preshared key, and choosing proposals. I've left in the NAT-T option, only because if other people are going to be using the VPN, and have NetScreen Remote clients, they'll be able to benefit from this. If the NetScreen doesn't see a need for NAT-T, it won't use it. Here's an example:
set ike gateway "dialupvpn" dialup "dialupusers" Aggr outgoing-interface "ethernet4/1" preshare "abc123" proposal "pre-g2-3des-sha" set ike gateway "dialupvpn" nat-traversal set ike gateway "dialupvpn" udp-checksum
3) Create the AutoKey IKE VPN
This is pretty straight forward. We set phase 2 proposals here, and specify our IKE gateway. I have replay-protection turned off, since I've seen some nasty problems when interoperating with foreign (non-NetScreen) implementations.
set vpn "dialupvpn" gateway "dialupvpn" no-replay tunnel idletime 0 proposal "g2-esp-3des-sha"
4) Create policies for the connection
This is a simple policy, it just allows the remote user to access everything on the internal subnet. I hope your policies are a little more secure.
set address "Trust" "192.168.10.0/24" 192.168.10.0 255.255.255.0 set policy top from "Untrust" to "Trust" "Dial-Up VPN" "192.168.10.0/24" "ANY" Tunnel vpn "dialupvpn" log
That's all that's needed on the NetScreen side. Hopefully the rest of the configuration on your firewall is in working order.
Linux/KAME Configuration: Dial-Up VPN
The 2.6-based kernel needs the following options:
- PF_KEY sockets (CONFIG_NET_KEY)
- AH transformation (CONFIG_INET_AH)
- ESP transformation (CONFIG_INET_ESP)
- IPCOMP transformation (CONFIG_INET_IPCOMP)
- DES, SHA1, (etc) from Crypto API
I've broken down the dial-up VPN setup into a four step process. I suppose this was somewhat arbitrary, but it's better than just one whole big step
1) Configure pre-shared key file
I edited /etc/racoon/psk.txt, then chmod'ed it to 400. Racoon complained when the mode was 600, although I'm not sure why. The file is basically just for IP and key pairs. Here's a sample of the file:
# ipv4/ipv6 adresses 1.2.2.2 abc123
2) Edit /etc/racoon/racoon.conf
There were a number of things I changed in this file. I hardcoded my current IP [172.16.1.2] in there. You'll have to change it to your current IP, every time it changes, if it does. Or, you can use a shell script contributed by Alexander Swen, which does this for you.
Anyway, here's some small pieces of the racoon.conf. You can probably get away with just this:
# Pre-shared key
path pre_shared_key "/etc/racoon/psk.txt";
- Remote host
remote 1.2.2.2 {
exchange_mode aggressive;
# Change this to your local ID
my_identifier user_fqdn "sampleuser@host.com";
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group modp1024;
}
}
- A sample sainfo section
- Create one for each subnet you want to access, etc.
sainfo address 172.16.1.2 any address 192.168.10.0/24 any {
pfs_group modp1024;
encryption_algorithm 3des;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
}
3) Modify /etc/ipsec.conf to reflect the policies set on the NetScreen
Again, you must substitute your current IP for the one I have listed [172.16.1.2]. I had to define both inbound and outbound rules. This tells the kernel what to encrypt and what to decrypt.
#!/usr/sbin/setkey -f
flush;
spdflush;
# outbound
spdadd 172.16.1.2 192.168.10.0/24 any
-P out ipsec esp/tunnel/172.16.1.2-1.2.2.2/require;
# inbound
spdadd 192.168.10.0/24 172.16.1.2 any
-P in ipsec esp/tunnel/1.2.2.2-172.16.1.2/require;
4) Start Racoon
Gentoo had a nifty init.d script to handle this, so I did an /etc/init.d/racoon start. I'm sure Debian and other distros have similar scripts. If not, you could probably get away with the following command run as root:
# /usr/sbin/racoon -4f /etc/racoon/racoon.conf
I suggest you read the notes, now.
Site-to-Site VPN
If you have a network at home, or wherever, and want to connect that entire network to another site, use this type of VPN. This assumes that your Linux box is already acting as some sort of router or NAT box on cable modem or other kind of dedicated connection.
Example addresses for the site-to-site VPN:
- 1.2.2.2 - public IP of the NetScreen
- 172.16.1.2 - current client address
- 192.168.2.0/24 - home private network
- 192.168.2.1 - private internal address of the Linux box
- 192.168.10.0 - private net, at remote site
- "abc123" - pre-shared key for the connection
- "sampleuser@host.com" - local IKE id
Example diagram:
/--------------------------\ /- -\
| Linux Router | ( )
| eth0: 172.16.1.2 |-------------- Internet
| eth1: 192.168.2.1/24 | ( )
\--------------------------/ \- -/
| |
| |
| |
/- -\ |
( ) /----------------------------\
192.168.2.0/24 | NetScreen Firewall |
Home Net | ethernet1: 1.2.2.2 |
( ) | [Untrust zone] |
\- -/ | ethernet2: 192.168.10.1/24 |
| [Trust zone, irrelevant] |
\----------------------------/
|
|
|
|
/- -\
( )
192.168.10.0/24
Private Net
( )
\- -/
NetScreen Configuration: Site-to-Site VPN
The basic steps on the NetScreen side to create the dial-up VPN consist of three steps: create the IKE gateway, create the autokey IKE VPN, and add policies. Since it's difficult to go over the steps needed in the web-UI, I'll outline the CLI commands that are needed.
1) Create the IKE gateway
Creating the IKE gateway consists of specifying the user group, setting aggressive mode, setting the preshared key, and choosing proposals. I've left in the NAT-T option, only because if other people are going to be using the VPN, and have NetScreen Remote clients, they'll be able to benefit from this. If the NetScreen doesn't see a need for NAT-T, it won't use it. Here's an example:
set ike gateway "sitetositevpn" address 0.0.0.0 id "sampluser@host.com" Aggr outgoing-interface "ethernet4/1" preshare "abc123" proposal "pre-g2-3des-sha" set ike gateway "sitetositevpn" nat-traversal udp-checksum
2) Create the AutoKey IKE VPN
This is pretty straight forward. We set phase 2 proposals here, and specify our IKE gateway. I have replay-protection turned off, since I've seen some nasty problems when interoperating with foreign (non-NetScreen) implementations.
set vpn "sitetositevpn" gateway "sitetositevpn" no-replay tunnel idletime 0 proposal "g2-esp-3des-sha"
3) Create policies for the connection
This is a simple policy, it just allows the remote user to access everything on the internal subnet. I hope your policies are a little more secure. Also, if you want, use a pair policy and reverse the source/destination pairs to allow traffic to be initiated in the opposite direction.
set address "Unrust" "192.168.2.0/24" 192.168.2.0 255.255.255.0 set address "Trust" "192.168.10.0/24" 192.168.10.0 255.255.255.0 set policy top from "Untrust" to "Trust" "192.168.2.0/24" "192.168.10.0/24" "ANY" Tunnel vpn "sitetositevpn" log
That's all that's needed on the NetScreen side.
Linux/KAME Configuration: Site-to-Site VPN
The 2.6-based kernel needs the following options:
- PF_KEY sockets (CONFIG_NET_KEY)
- AH transformation (CONFIG_INET_AH)
- ESP transformation (CONFIG_INET_ESP)
- IPCOMP transformation (CONFIG_INET_IPCOMP)
- DES, SHA1, (etc) from Crypto API
I've broken down this setup down to a seven step process. I suppose this was somewhat arbitrary, but it's better than just one whole big step
1) Configure pre-shared key file
I edited /etc/racoon/psk.txt, then chmod'ed it to 400. Racoon complained when the mode was 600, although I'm not sure why. The file is basically just for IP and key pairs. Here's a sample of the file:
# ipv4/ipv6 adresses 1.2.2.2 abc123
2) Edit /etc/racoon/racoon.conf
There were a number of things I changed in this file. I hardcoded my current IP [172.16.1.2] in there. I also hardcoded my private subnet [192.168.2.0/24]. You'll have to change it to your current IP, and private subnet you're using. I haven't figured out how to have it autodetect the IP bound to the egress interface, yet. I suppose one could write a small shell script with sed and awk, to automate this.
Anyway, here's some small pieces of the racoon.conf:
# Remote host
remote 1.2.2.2
{
exchange_mode aggressive;
# Change this to your local ID
my_identifier user_fqdn "sampleuser@host.com";
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group modp1024;
}
}
# A sample sainfo section
sainfo address 192.168.2.0/24 any address 192.168.10.0/24 any
{
pfs_group modp1024;
encryption_algorithm 3des;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
}
3) Modify /etc/ipsec.conf to reflect the policies set on the NetScreen
I had to define both inbound and outbound rules. This tells the kernel what to encrypt and what to decrypt.
#!/usr/sbin/setkey -f
flush;
spdflush;
# outbound
spdadd 192.168.2.0/24 192.168.10.0/24 any
-P out ipsec esp/tunnel/172.16.1.2-1.2.2.2/require;
# inbound
spdadd 192.168.10.0/24 192.168.2.0/24 any
-P in ipsec esp/tunnel/1.2.2.2-172.16.1.2/require;
4) Start Racoon
Gentoo had a nifty init.d script to handle this, so I did an /etc/init.d/racoon start. I'm sure Debian and other distros have similar scripts. If not, you could probably get away with the following command run as root:
# /usr/sbin/racoon -4f /etc/racoon/racoon.conf
I suggest you read the notes, now.
Notes
There are a few gotchas with these types of VPN setups, I'll try to list some of them here."
- With the site-to-site VPN, don't freak out if you can't connect to the remote network from the Linux router itself. The connections are going out the egress interface [172.16.1.2] by default, and the KAME stack isn't going to encrypt them. To fix this, you might be able to add a couple more lines to /etc/ipsec.conf, to encrypt connections coming from the egress IP. You'll probably have to add a policy or two on the NetScreen, with a source of "Dial-Up VPN." Of course, this might not work, I haven't tried it. For a quick fix, just have whatever app you're using bind to the eth1 IP, like "ssh -b 192.168.2.1 192.168.10.10."
- The first couple connections will fail when the tunnel is being established. You'll get something like "resource temporarily unavailable," or it might just hang, until the IKE negotiations have completed. If you keep getting that message after 10-15 seconds, it's time to look in the logs, something's wrong.
- I've noticed that the NAT-T function does not work, yet. For now, the tunnel traffic will be sent over the network via pure ESP, IP protocol 50. Most NAT implementations seem to deal with this fine. I've tested it with a Linux box doing NAT and some Cisco NAT box at a hotel I was staying at recently, both work fine. However, certain corporate environments will drop, or corrupt, the ESP packets. YMMV ...
I actually received some info about the NAT-T problem on the NetScreens from Will Drewry
So it looks like NetScreen has a "bug" that makes them not support NAT-t draft 02 during negotiation. I've heard that it will be fixed in ScreenOS 5.1, but you never know. If you watch the connection, you'll see that they present the md5 hash for draft 00 and nothing else, but NetScreen remote client, however, seems to force draft 2 without even negotiating... (Update, 2005/10/18) Netscreen's 5.1.0r* releases did indeed fix the negotiation bug, however they introduced a nasty L2TP problem (fixed after r1 or r2 I think).
If the NetScreen rejects the "set ike gateway ... " commands you're sending it, don't worry, it's probably because you're running ScreenOS 5.x. Most of these commands, with the exception of this one, will work fine on both ScreenOS releases. The syntax for this one has simply changed, I think you have to do something like "dynamic" instead of using "address 0.0.0.0." No idea why they had to change this, both make sense.
Questions or suggestions? Feel free to contact me at prox@prolixium.com. I'd like to thank Garren Hochstetler and Will Drewry for contributing to this document.