It's nice to have a router now with enough throughput to saturate a 100 mbps line. PCNation was kindly able to exchange the 892fsp I bought (not realizing it hums along somewhat under 100mbps in most cases once you add some NAT rules to it) for something less fancy but a hell of a lot faster. (Claims to do 800mbps on IPSec!) Not planning on taking my CCNA anytime soon anyway.
So here it is in all its glory:
For now it's unceremoniously proped up on a chair in my living room. If you're thinking of getting one for home or office note that the damn thing is loud. It sounds like a leafblower, must be kept in a server room or a closet if you want to be able to hear yourself think.
For an amateur network technician such as yours truly having a web based interface for configuration is nice too. Spending all day configuring the 892fsp was fun and all but I was up and running with a basic configuration on this one within an hour.
So aside from the horrific volume there were another few expensive learning experiences from this endevour. First, you can't just configure this router to act like a switch. The consumer grade router I had before is really a router with a single interface connected to a 4 port switch, which you can't really replicate on a device with a bunch of routed interfaces (how would you configure the route table?) So all my physical hosts, which used to have static IP addresses on a single subnet, needed to be moved each to their own subnet, and the virtual hosts running on them needed to change to match. Once the subnet situation was sorted out the routing was very easy, I just kept them all on the same zone and traffic could move between them freely.
Replicating the port forwarding rules from the Netgear router was very easy also. Each port forward rule on the Netgear is a combination of a NAT rule and a Firewall rule on the ZyWall. Each NAT rule has a nice option for NAT loopback which means the DNS rules inside the network can more or less stay the same for public facing services that are OK to route through the internet. Lync autodiscover for mobile in fact by default returns the external sip url even when accessed internally:
The default configuration is to direct all mobile client traffic through the external site. ... To define this configuration, you use the Set-CsMcxConfiguration cmdlet.
With the loopback feature Lync and other interface facing services keep working inside the network out of the box, no split DNS or additional SANs on the certificates are required.
So the whole point of this was to get IPSec to AWS working, here are the steps to do it:
IPSec to AWS
First, get yourself a VPC. The wizard makes it easy:
Choose the one with a nice public and private subnets and hardware VPN:
You can handle the rest of it, the wizard is easy.
Now, make sure you have a hardware VPN that's not behind a NAT device. The Zywalls are cost effective and fast but doesn't much matter as long as it supports IPSec VPN.
On your AWS dashboard go to the VPN section under VPC:
Then select your VPN connection and download the configuration
Download the configuration for your particular router, or if it's not listed
then just grab the generic one.
From here on the instructions only apply to the ZyWall.
The generic configuration file contains parameters and basic instructions to help you get the router set up. It contains two separate tunnel configurations for the sake of redundancy. For now lets just configure one of them.
In the ZyWall admin go to IPSec VPN and create a new gateway
Click show advanced settings because we'll need to set some that are hidden by default.
The following configurations need to be set on the VPN gateway:
- Make sure the Enable checkbox is checked :-)
- Name your gateway
- Under "My Address" choose "Interface" and select the WAN port you're using
- Under "Peer Gateway Address" choose "Static", set "Primary" to the "Virtual Private Gateway" outside interface specified in the amazon configuration file you downloaded. The secondary ip just leave 0.0.0.0 for now, one thing at a time.
- For "Authentication" select "Pre-Shared Key" and put in the value for the IKE SA PSK from the config file
- Set the SA Life Time to the value from the config file (28800 for me)
- Negotiation mode is main
- Add a proposal AES128 for Encryption and SHA1 for Authentication
- DH2 for Key Group
- Enable Dead Peer Detection, disable NAT
- Disable extended authentication
- Save it
Looks like this:
Now go to the VPN tab and create a new connection. You'll need to click show advanced settings here too:
- Ensure Enable is checked :-)
- Name your connection
- MSS adjustment is a custom size, you can find it in the config file, mine was 1387
- Application scenario is site-to-site
- Select the VPN gateway you created in the previous step
- For Local Policy, select the subnet that represents your INSIDE Network. Create one if it doesn't exists. I set mine to 192.168.0.0/16.
- For Remote Policy, select the subnet that represents the inside network on the AWS side. Create if it doesn't exist. Mine was 10.168.0.0/16.
- Under Phase 2 setting, set the lifetime from the config file. Mine was 3600.
- Active protocol is ESP
- Encapsulation is Tunnel
- Proposal is AES128 / SHA1 again
- PFS is DH2
- For the zone (for initial simplicity) I put it on the same zone as the LAN to allow all traffic. Better idea would be to put it on its own zone and configure appropriate firewall rules to control traffic between the vpn zone and the lan zone.
- The connectivity check option isn't really optional. The dead connection detection on the AWS side will close the VPN tunnel if it doesn't get a stead stream of traffic. I set mine to sent an ICMP packet through the tunnel every 15 seconds to a VPC host to keep the tunnel open.
That's it on the router side. Looks like this:
If working you get a connection icon. If not, start digging in the logs.
On the AWS side, you need to configure two static routes: one on the applicable vpc route table routing your local subnet through the virtual private gateway (the device id beginning with vgw-), and the other as a static route to the same local subnet on the VPN connection itself.
All done! Here's a ping from a workstation on the internal network to a domain controller I added in the VPC.