This document details how to configure IPSecuritas, working with Xauth and dynamic IP pools using a route-based VPN. It is within the realm of possibility that I will eventually upload screenshots of the configuration, but don’t count on it. Sorry for the brevity, but I’m fairly busy these days.

This document is organized into two parts. The first part is the Xauth configuration on the firewall. The second part is the configuration of IP Securitas. Skip the first part if your your dialup VPN with Xauth is already working with other clients.

NetScreen Configuration

There are several steps we need to accomplish here to make this work:

1. Create a new tunnel interface, unnumbered, and in the zone you want the VPN terminated. If you are accessing hosts in your trust zone and terminate the VPN in the trust zone, then you do not need to put in any policies. However, if you terminate the tunnel in a different zone from the hosts you are accessing, you will need to create a policy to allow this traffic.
2. Create an IP Pool. This pool should NOT overlap with other addresses in use on the network. In the GUI, you create this under Objects->IP Pools. I called mine RAS-pool and it goes from 10.128.2.1 to 10.128.2.10. This will support 10 users.
3. Create an IKE user and place the user into a group. This IKE user will be used for everyone in my configuration. Essentially, I’m using this user to group my users together. In the event that I had different types of users with different access, I could create different VPN’s that used different IKE ID’s in order to hand out IP addresses from different pools and control access to the whole group by policy. Under Objects->Users->Local, create a new user. Name the user something like vpn@mydomain.com, check the IKE User box, leave the identity as Auto and put vpn@mydomain.com there also. Then set the number of simultaneous users. If this number is more than one, then we need to put this user into a User Group. Create a User Group and add this user to it. I called mine XAuth-Global.
4. Create your XAUTH users. Objects->Users->Local, create a new user. Enter the username. Select the XAUTH User checkbox, and enter the password. Click OK. Place the user into a group. I called mine RAS-users.
5. Create your Phase I. VPN’s->AutoKey Advanced->Gateway. Create new. I called mine “ras-gw”, select Dialup User Group and select your XAUTH-Global group. Enter the preshared key, or on newer versions click Advanced and then enter the PSK. Select a proposal. I suggest pre-g2-aes128-sha. Select Aggressive Mode. Enable NAT-T. Click Return, click OK.
6. Set your default XAuth settings. VPNs->AutoKey Advanced->XAuth Settings. Set the IP pool name to RAS-pool, and set your DNS servers. Click OK
7. Click the XAUTH link next to your Phase 1 you just created. Set the XAuth server to Generic. Set it to Local Auth, and set the user group to RAS-users. Click OK.
8. Create Phase 2. VPNs->AutoKey IKE. Create new, I named mine ras-vpn. Set the remote gateway to predefined and choose your ras-gw. Set your proposal to custom, I suggest g2-esp-aes128-sha. Bind to your tunnel interface created in step 1. Check Proxy-ID. Local Proxy ID should be a subnet that attempt to encompass everything your clients will access. Remote proxy ID should be 255.255.255.255/32. Click Return, click OK.
9. Create a destination route that points to your tunnel interface for the network that your IP pool uses. My route is 10.128.2.0/24 via tunnel.2. Ignore the other stuff in there, you don’t need it.
10. Optionally create an access-list and route-map that you can use in your redistribution rules if you are running dynamic routing and want remote sites to be accessible to the clients. This is out of scope of this doc, but remember you might need this if users come into a central site and need access to other sites or you have layer-3 routing internally.
11. Done!

IP Securitas Configuration

Unless it says below to change it, leave the default setting.

1. Under the top menu, Connections->Edit Connections. Create a new connection with the “+” button.
2. Under the “General Tab”, enter the IP or hostname of your firewall. For remote side, choose network and enter the same network you entered in the Proxy ID section for the Local address in step 8 above.
3. Under phase 1, Lifetime = 28800 seconds, DH Group 2, AES 128, SHA-1, Aggressive mode.
4. Under Phase 2, Lifetime = 3600 seconds, PFS Group 2, select AES 128 under encryption, and HMAC SHA-1 under authentication.
5. Under ID. Local Identifier = User FQDN (vpn@mydomain.com), Remote Identifier = Address, Auth Method = Xauth PSK, then enter the preshared key, and your username/password that you placed into the RAS-users group above.
6. Under the Options tab - Leave everything alone except for these: Check “Enable MODE_CFG”, check “Local IP in Remote Network”, set NAT-T to enable. Optionally, you can enable the connection check and put in the address you want it to ping. I would wait and make sure things come up first, or this will keep bringing the connection down if it’s inaccessible.
7. Done!

Press Start and everything should work!

I finally found some time to sit down and get this thing working. I'll write up a more detailed Howto eventually, but I wanted to get this out there for those that want it working now. Also, if anyone figures out how to create a route based version of this, please PM me. I could not make the route based configuration work.

There are a couple of requirements:
1. You must use certificates. The Mac VPN client will send its internal IP as the IKE ID if you use PSK's. This doesn't work well for clients that get a dynamic address or roaming laptop users.
2. As of now, the VPN must be policy based. I cannot make it work with a route based config, as the client sends its internal address for the source network in the proxy-id. The client is not very configurable.

The first thing we need to do is create certificates. You will need a machine certificate on your mac, and a VPN server certificate on your firewall. The CA cert will need to be loaded on each device, and you will have to place it in the System Keychain on the Mac to make it trusted. I created my own CA using the Certificate Assistant on the Mac.

1. Create the CA - Open Keychain Access, and under the Keychain menu at the top, go under certificate assistant and choose "Create a certificate Authority". Follow the prompts to get it created. Once it is created, drag a copy to the desktop, and then drag the file to your System keychain. If you drag it directly from one keychain to another, it will move it, not copy it. Make sure you choose a unique serial number when you get to that point.

2. Create the Machine certificate - User Certificate Assistant to create a new cert. Call it "VPN client Cert" or whatever you want. This is a Leaf certificate, not a self-signed. Select the box that lets you override options. The email address should be vpn@yourdomain.com, or whatever you plan on using for an IKE ID on the Juniper. Set a unique serial number. You should choose 1024-bit/RSA. Uncheck the "Critical" checkbox, and only check Signature and Key Encipherment. Include Extended Key Usage, uncheck critical, check SSL Client, SSL Server, PKINIT Client, and PKINIT Server. Uncheck Basic Contraints in the next screen, and uncheck Subject Alternate Name in the one after that. Select your System Keychain to store it.

3. Load the CA Cert on the Juniper. Create a CSR, and make sure the FQDN or the IP Address is set to *exactly* what the VPN client will point to. Save the CSR. Start the certificate assistant again and select the "create a certificate for someone else" option. Drag the CSR onto the area it tells you to. You must override the options for this one also. You need to select VPN Server, make sure the "Extended Key Usage" option is UNCHECKED. Include a Subject alternate name, and fill in either the DNS name or the IP. The other fields should be blank, only fill in one of them. Once the cert is created, you will need to load it on the Juniper.

4. You MUST create a CRL. Certificate assistant doesn't have an option for this. You'll have to use OpenSSL to do it on the command line. I don't have the instructions in front of me now, but you'll just want to create a blank CRL. Search google for now, I'll put up instructions when I get around to it.

(Note that there are bugs with the Keychain on both Leopard and Tiger. Google can help with some of them. But, on Leopard, I noticed if you delete *anything* from the keychain, you cannot create certificates again until you reboot. Also, it is imperative you choose unique serial numbers for all of your certs. If you do not, you can possibly corrupt the keychain, just ask me how I know.)

---- Configure the Mac (Leopard instructions)
1. Open Network under the System Prefs. Add a new interface, choose L2TP over IPSEC. Name it something. At the drop down menu at the top, you MUST change it from Default and add a new configuration called something else. If you do not, it will not take your machine cert... Bug?
2. Put in the hostname or IP that you used in the Subject Alternative Name section in your Juniper cert.
3. Put in the desired username.
4. Click on advanced and put in the password.
5. Under the Machine Authentication Section, select certificate, then select your machine cert. Click OK.
6. Click Apply.

You can either find the checkbox that says "Send all traffic over the VPN", or you can manually enter routes when you connect: route add -net 10.1.1.0/24 -interface ppp0

I'm researching DHCP option 121 to see if this can be used in conjunction with L2TP to push routes down to the client. Let me know if you find anything.

---- Configure the Juniper
These are fairly abbreviated instructions, but should get you started.

1. Configure a user. Select IKE User, Simple Identity, Auto, and for the IKE ID, put in "Email=vpn@yourdomain.com" or whatever email addy was put in your Machine cert
2. Select L2TP user
3. Click OK
4. Add that user to a group if there is going to be more than just one person using the VPN
5. Configure an IP pool
6. Configure your L2TP tunnel, choose the IP Pool you just created, and set up whatever DNS/WINS settings you want
7. Create a P1 proposal with RSA/DH Group 2/3DES/SHA-1/3600 sec lifetime
8. Create a P2 proposal with NO PFS/AES-128/SHA-1/3600 sec lifetime
9. Create an Autokey IKE gateway with your User or User Group, click advanced, Choose your P1 proposal, NAT Traversal if needed (likely), Your Juniper cert you created, the CA Cert you loaded, and PKCS7 (Might work with X509-sig also)
10. Press Return, then OK
11. Create a new Autokey IKE VPN. Choose your new gateway, click advanced, Choose your P2 proposal, Transport mode, Hit return, then OK.
12. Create an Untrust->Trust policy. Source is Dialup VPN, Destination is your internet networks. Action is Tunnel, choose your VPN and your L2TP tunnel. Position at Top. Click OK.

It should now work. Make sure you test from the outside. By far the worst part of this is the certificate stuff. The subjectAltName must be set in the cert loaded on the Juniper and the Extended Key Usage option must NOT be set, or the OSX client will throw it away. Also, you must ensure that the CA Cert is loaded into your System Keychain and marked as Trusted for all users, or it will not trust the cert given to you by the Juniper. The CRL must also be loaded on the Juniper, I couldn't find a way to make it not check that, even though there is an option to ignore it. You *could* use the same machine certificate for all of your clients if you really wanted to, because they are still authenticating with user/pass for L2TP. But, it's definitely better that every gets their own certificate. I'll say this again also, make sure you have unique serial numbers for all of your certs. I ended up having to delete my System keychain several times because I didn't pay attention and just assumed that the certificate assistant would autoincrement my serial numbers for me.

I hope this helps. There may be some unnecessary options checked in the machine cert, but those were the only ones I could check to get it to actually show up as a valid machine certificate on the Mac. Sorry for the less than detailed instructions, but I wanted to get something up there while I had some time. If anyone wants to take some screenshots during the process and send them to me, I'll whack up a better Howto and toss them in there.

"Global" does NOT mean "any zone." The Global zone is a special zone where only VIP's and MIP's reside. All VIP's and MIP's reside in the Global zone. If you create a policy from Untrust->Trust which contains a MIP and then do a "get policy id " on that policy, it will show that the policy's destination zone is actually Global, not Trust. Since the global zone only has MIP's and VIP's in it, it *cannot* be used to log all of the dropped traffic passing through the device.

Remember that the Global zone is only for policies which contain MIP's and VIP's and will not have an effect on anything else. The Global Zone does not mean "all zones.". If you want to put in an explicit deny at the end of your policy for logging, you must create a Global policy. Now, here's where it gets interesting. There is something called the Global policy. The Global policy has nothing to do with global zones. This policy is parsed after zone->zone policies and intrazone policies. By default, there is nothing in it and it allows all traffic. Any rule in the Global policy applies to all source and destination zones. If you type "get policy" it will only show you your regular zone->zone and intrazone rules. If you type "get policy global" it will show you the global policy. To set a catchall deny policy that logs, issue the command:

set policy global any any any deny log

Or, in the Web interface, select Global as the source zone and Global as the destination zone. Apparently this method of creating the Global policy will also work in NSM, however, I was not able to make it work with version 2007.1r1. I will investigate further and make changes to this article as needed.

I should also mention that the content of this article was changed. I was incorrect with some of my assumptions, to which a few people pointed out. Thanks!