Scenario 1: Gateway-to-gateway with preshared secrets The following is a typical gateway-to-gateway VPN that uses a preshared secret for authentication. 10.5.6.0/24 172.23.9.0/24 | | --| |-- | +-----------+ /-^-^-^-^--\ +-----------+ | |-----| Gateway A |=====| Internet |=====| Gateway B |-----| | AL+-----------+AW \--v-v-v-v-/ BW+-----------+BL | --| 10.5.6.1 14.15.16.17 22.23.24.25 172.23.9.1 |-- | | Gateway A connects the internal LAN 10.5.6.0/24 to the Internet. Gateway A's LAN interface has the address 10.5.6.1, and its WAN (Internet) interface has the address 14.15.16.17. Gateway B connects the internal LAN 172.23.9.0/24 to the Internet. Gateway B's WAN (Internet) interface has the address 22.23.24.25. Gateway B's LAN interface address, 172.23.9.1, can be used for testing IPsec but is not needed for configuring Gateway A. The IKE Phase 1 parameters used in Scenario 1 are: * Main mode * TripleDES * SHA-1 * MODP group 2 (1024 bits) * pre-shared secret of "hr5xb84l6aa9r6" * SA lifetime of 28800 seconds (eight hours) with no kbytes rekeying The IKE Phase 2 parameters used in Scenario 1 are: * TripleDES * SHA-1 * ESP tunnel mode * MODP group 2 (1024 bits) * Perfect forward secrecy for rekeying * SA lifetime of 3600 seconds (one hour) with no kbytes rekeying * Selectors for all IP protocols, all ports, between 10.5.6.0/24 and 172.23.9.0/24, using IPv4 subnets To set up Gateway A for this scenario, use the following steps: 1. configure the interfaces 2. configure the routes 3. configure the firewall 4. configure the ike policy 5. configure the ipsec policy Getting Ready ------------------ Connect the provied serial cable between the Nortel Secure Router and a PC with a terminal emulator program. Configure your terminal emulator program to run at 9600 baud, No stop bits, 8 bit. Expect the Secure Router bootup to take several minutes. The Secure Router provides a login promt before it is finished initializing, wait until the "System ready" prompt comes up. Then you may log in with your username and password. The default username and password as shipped from the factory is "admin"/"setup". From the main prompt you may enter the configuration mode with the `configure terminal` command. For example, from the configuration prompt, you may set the hostname: hostname alice Exit the config mode and from the main prompt, review your current configuration with `show running-config` and save your current configuration with `save local`. Step 1. configure the interfaces ----------------------------------- The Nortel Secure routers have different interface names depending upon the model. The ethernets on the 100X series are "ethernet 0" and "ethernet 1". In the 3xxx and 4xxx series are modular devices and have a slot/port naming convention like "ethernet 0/0" and "ethernet 0/1". Through out this example, we will used the 'fixed' naming convention of "ethernet 0". We will configure the Secure Router as "Gateway A" in the "Scenario 1: Gateway-to-gateway with preshared secrets" with ethernet-0 being the trusted side and ethernet-1 being the untrusted side. Enter configuration mode and configure the ip address on ethernet0 and set it to be a trusted interface. interface ethernet 0 ip address 10.5.6.1 24 crypto trusted exit And configure ethernet-1 with its address and set it to be an untrusted interface: interface ethernet 1 ip address 14.15.16.17 24 crypto untrusted exit Use `show ip interfaces [brief]` to confirm their configuration and status. Step 2. configure the routes ----------------------------------- In general, the Secure Router needs to know the route to both the source and the destination protected networks -- this is a firewalling requirement. In the VPNC, Scenario 1 case, a simple, default static route will do: ip route 0.0.0.0 0 14.15.16.1 ^^^^^^ ^^^^^^^^ ^^^^^^^^^ address prefix next-hop Use `show ip route` to confirm the configuration and status. Step 3. configure the firewall ----------------------------------- In the Secure Router, the firewall functionality may not be seperated from the VPN functionality. Therefore the firewall policies must admit IKE (and in our example, we will also admit icmp) to the untrusted interface. firewall internet policy 100 in permit service ike self exit policy 101 in permit protocol icmp self exit exit The firewall policies must also allow inbound traffic from the far end trusted network. firewall corp policy 100 in permit address 172.23.9.0 24 10.5.6.0 24 exit exit By virtue of the `crypto trusted` and `crypto untrusted` commnads given on the interfaces, ethernet0 will already be assigned to the 'corp' firewall and ethernet1 will already be assigned to the 'internet' firewall. Use `show crypto interfaces` and/or `show firewall interfaces all` to confirm. Step 4. configure the ike policy ----------------------------------- The IKE terminology in the VPNC "Scenario 1: Gateway-to-gateway with preshared secrets" is strongly similar to the CLI terminology in the Nortel Secure Routers. The VPNC term "MODP Group" maps to the Nortel Secure Secure Router CLI term of "dh-group". Also, the VPNC example calls for PFS to be used in the IPsec parameters. The Nortel Secure Router CLI 'enables' PFS in the IKE parameters, but specifies which pfs-modp-group will be used in the IPsec parameters. The Secure Router will configure an IKE policy named "vpnc1" with one proposal as such: crypto ike policy vpnc1 22.23.24.25 local-address 14.15.16.17 key hr5xb84l6aa9r6 proposal 1 dh-group group2 encryption-algorithm 3des-cbc lifetime seconds 28800 exit exit exit The Secure Router's default ike mode is 'main' and default hash algorithm is SHA1 and default kilobyte lifeime is unlimited, so these not need to be explicitly configured. The Nortel Secure Router provides support for up to 5 propsals in IKE, though only one is needed here. Take note that we have *not* configured the ike level `pfs` command which you may find available if you type a `?` in the "ike" subtree. The `pfs` command here would enable PFS-with-respect-to-identities. The PFS type we are interested in for VPNC compatability is PFS-with-respect-to-keys and that is configured in the next section in the `ipsec` subtree. PFS with respect to identities would delete the phase1 SA immediatly after the first phase2 use. And this behavior may cause interoperability problems with some other vendors who do not expect this (rare) type of PFS. Confirm your IKE configuration with `show crypto ike policy all [detail]`. Step 5. configure the ipsec policy ----------------------------------- The IPsec terminology in the VPNC "Scenario 1: Gateway-to-gateway with preshared secrets" is strongly similar to the CLI terminology in the Nortel Secure Routers. The VPNC term "MODP Group" (in phase 2) maps to the Nortel Secure Secure Router CLI term of "pfs-group". Also, the VPNC example calls for PFS to be used in the IPsec parameters. The Nortel Secure Router CLI 'enables' PFS in the IKE parameters, but specifies which pfs-group will be used in the IPsec parameters. Configuring Phase2 selectors in the Secure Router is done through the `match address` command which will only configure subnet type selectors. The Secure Router will configure an IPsec policy named "vpnc1" with one proposal as such: crypto ipsec policy vpnc1 22.23.24.25 match address 10.5.6.0 24 172.23.9.0 24 pfs-group group2 proposal 1 esp lifetime seconds 3600 exit exit exit crypto The Secure Rotuer's defaults for encryption, hash, tunnel-mode, and kilobyte lifetime all match the VPNC example and do not need to be explicilty configured. The Nortel Secure Router provides for up to 5 AH and 5 ESP proposals to be configured. Proposals with the same number are "AND"ed together (ie AH 1 and ESP 1). Proposals with different numbers are in an "OR" list (ie (AH 1 AND ESP 1) OR (ESP 2)). Only one ESP proposal is needed in the VPNC example. Also note that we have enabled PFS here at the `ispec` level. In the Secure Router implementation, this is PFS with respect to keys which is the particular type of PFS of interest in this VPNC scenario. PFS with respect to keys forces the use of the optional DH exchange in phase 2. Confirm your IPsec configuration with `show crypto ipsec policy all [detail]`. Confirm your entire current configuration with: `show running-config` Save your config with `save local` ---------------------------------------------------- After configuration you are ready to check network conectivity and attempt to pass traffic and trigger the SA establishment. It is always best to watch these first attempts (fail) with debug on. The Secure Router provides a `ping` command for checking network connectivity. Set the console debug sensitivity to debug with `system logging console debug` from the config prompt. And enable these debug options from the main prompt: `debug crypto all` `debug firewall all` `debug firewall packet` (no `debug firewall all` does not include `debug firewall packet`, and yes there are reasons) The no form of these commands turns off debug: `no debug crypto all` `no debug firewall all` `no debug firewall packet` `no debug all` (optional) Step 6. configure for telnet or ssh connectivity -------------------------------------------------------- If you wish to untether yourself from the serial console, you may arrange for a telnet or ssh server to run in the Secure Router. To start up the telnet server, at the config prompt, to this: telnet_server save local To start up the ssh server, you need to both generate a key and start the server: ssh_keygen generate [rsa|dsa] exit ssh_server save local If you wish to connet to the telnet or ssh server from the untrusted side, you will need a firewall policy to allow such: firewall internet policy 102 in service ssh self policy 103 in service telnet self exit save local And finally, if you wish to see the console messages on your remote shell, go to the config prompt and enter: terminal monitor