Chapter 9
Leave My WAN IP and Remote Gateway IP on 0.0.0.0/0 for now. Set the Remote Network IP
(lowest IP in the subnet range) and the Remote Network Mask. Do not select More. Disable RIP and set For NAT operation, treat remote sub-net to Private IP.
Depending on how you configure the Openswan end, select or deselect Change the default route through this VPN tunnel. Select OK.
Windows Logon Issues
The VPN tunnel (lan-to-lan profile) seems to work best if you leave the WAN IP at 0.0.0.0. This allows the tunnel to work even if the Vigor's IP address on the outside changes. However, if pinging through the tunnel works, but the Windows logon fails with an obscure Active Directory DNS error, then you should try to change the WAN IP to the IP address you receive from your ISP's DHCP server. That solved the Windows Logon problem for us. Of course this type of setup requires that you use an ISP connection with a static IP, or you will have to fix your IPsec connection every time your ISP changes the IP address on you.
When you have completed this section, you can go through the pop-ups that you have skipped before, such as the Advanced pop-up, which is the only one you should need.
Here you can set Main mode or Aggressive mode, and enable or disable PFS. The Vigor's defaults have changed over time. For Openswan, choose Main mode and enable PFS. Leave the Local ID blank unless you need to specify one in ipsec.conf.
There is an IKE Phase 1 proposal pull-down menu, corresponding to Openswan's ike= setting. The only menu option that allows you to suggest a variety of options (both SHA1 and MD5, 3DES and AES, and DH group 1 and 2) will unfortunately also suggest 1DES. Worse, 1DES will be announced before 3DES, and DH group 1 before DH group 2, so you will always see an error on the Openswan end rejecting the first request for 1DES, and it will end up using a weaker DH group than necessary. We recommend setting this option specifically to 3DES_SHA1_G2.
Our findings were verified against the latest released firmware, dated June 1 2005. All bugs mentioned are still present in that version of the firmware.
223
Interoperating with Other Vendors
Other Vigorisms
The Vigor calls AH Medium Security and ESP High Security. You will most likely want to disable all Medium Security options. The High Security modes come with 3DES, AES, and DES. You should always unselect DES as Openswan rejects the outdated (and insecure) DES mode by default. The Vigor also allows ESP without authentication, which is insecure and rejected by Openswan. Do not pick these options. Stick to 3DES or AES with authentication.
Another problem we have observed is that the Vigor can be very liberal in what it expects, so that the initial connection establishes without a problem, but that on a later rekey time, it will request something Openswan will refuse. We have seen this happen when disabling Perfect Forward Secrecy on the Vigor and enabling pfs=yes (the default) on Openswan. Of course, this is the mistake of the administrator, and not the device, but it could be quite a difficult problem to diagnose.
Unresolved Issues
As of version 2.55 (for the Vigor2500), there are still a few unresolved problems with the Vigor firmware, as detailed in this section. These might have been fixed by the time you're reading this. Check the Openswan interop pages for up-to-date information.
IPsec SA Limitation
The most important issue is that you cannot have two IPsec tunnels with the same two endpoints. Although we successfully established multiple tunnels with the same endpoints using a beta version of the firmware DrayTek gave us for testing the Vigor2600, this patch has not made it to the other models yet. With the buggy firmware, you will receive a Delete SA request for the first tunnel when you try to bring up the second tunnel. DrayTek considers this a feature request instead of a bug report and it has a low priority with its R&D department. If you need to set up multiple tunnels to the same VPN gateway, a common requirement for larger companies who have multiple locations with different subnets, then you should avoid Vigor units unless you can confirm that DrayTek has fixed this issue. This is irrespective of whether you define two separate lan-to-lan tunnels or use the More option to add the second tunnel. The second method has the additional problem that when you dial the VPN tunnel, only the first network is actually established with an IPsec SA. To bring up the second tunnel requires an initiation from the other (Openswan) end. According to DrayTek this is the normal behavior, and the Vigor would indeed send packets over the first tunnel with the second tunnel's IP address. This has not been verified by the Openswan team, because we simply can never work with such a solution, because Openswan would (as it should!) reject those packets, since they do not match any SPD/SAD entry.
Rekeying Issue
The Vigor sends a Delete SA request after its timeout has occurred. On Openswan 1 this informational message is ignored, and the result is a %trap eroute. The connection can't be triggered again within the Openswan's keylife, since it will ignore unencrypted IKE traffic sent by the Vigor as it believes it has a proper tunnel up. Upgrade to Openswan 2, which properly handles Delete SA requests.
Phase 1 Resets
If you change any Phase 1 (IKE) parameters, and you have already established a Phase 1 (ISAKMP) connection to the remote end, that ISAKMP will not be torn down. You must reboot the Vigor for your changes to take effect.
224