Tunnel to the Cloud: Azure Site to Site IPsec Connection

Do you have multi-continent datacenters with gobs of bandwidth, IOps, and processing capability? No? I can help get you part of the way there... a network presence in one.

A tunnel.

A Site to Site Connection?

It's easier to think of this as an extension to your network into another datacenter over the internet. Using IPsec we can provide a relatively (comments at the end) secure, direct connection between on on-premises datacenter and Azure hosted resources by encrypting the traffic that flows between the two.  What do I mean by:

• Secure: IPsec tunnels all your traffic so it is encrypted over the internet; in reality, this is really "more secure" rather than definitively secure, as the effective security depends highly on implementation specifics.
• Direct: Your router (played by pfSense in this case) will recognize the Azure site as another routable network within the boundaries of your own, enabling you to talk to Azure resources as if they were in your own datacenter.

While I'll be using pfSense for the initiator side as it exposes the options in the most clear way I've found, this article will also be useful for non-pfSense devices since we discuss the details of the IPsec tunnel; the information here should be applicable to any IPsec solution. Update 1/2017: I've personally tested on various Cisco, Sonicwall, and pFsense equipment, and Microsoft has added some great documentation about overall device support here.

Note: this works for Amazon Web Services (AWS) as well but is slightly more complex. Fortunately pfSense includes a wizard that works, but takes a lot of the fun out of it as it strips you of understanding how it works. In addition the wizard is necessary because of how Amazon does VPC routing, whereas Azure is a bit more straightforward.

With that, let's get to it!

Pre-Requisites

• pfSense firewall(s): The steps in this article were performed on a pair of  HA SG-4860 firewalls running pfSense 2.32p1.
• Microsoft Azure account with adequate permissions: We'll be performing our actions using the "new" portal based on Azure Resource Manager (ARM or AzureRM).
• AzureRM PowerShell Cmdlets installed: On Win10/Server 2016 this can be accomplished with Install-Module AzureRM; for more info see this post.

Configure Azure IPSec Endpoint

Before we set up and initiate the connection from pfSense, we need to set up our endpoint in Azure. To do so, we'll create the following objects:

• A Resource Group
• A Public IP Address
• A Virtual Network
• A Gateway Subnet
• A Virtual Network Gateway
• A Local Network Gateway with a Connection

Resource Group

A Resource Group is a logical grouping of Azure Resources. This logical group allows for easy organization and clearer billing reports. We won't get too much into concepts and naming standards here other than to say groups should be logically tied with similar lifecycle expectancies and you should be consistent. For more information, see this Azure article.

Note: We'll be doing most of our steps in the web portal, but this whole process is much more efficient with PowerShell.

Let's go!

1. Open and log into the ARM Azure Portal at portal.azure.com; ensure you're working with the subscription you intend to use.
2. Navigate to "Resource Groups".
3. Click "Add" and type a name for your resource group, select the subscription, and resource group location. Note: The resource group location has no bearing on where you'll be connecting to as it's just a location the metadata is stored.
4. Click "Save".

Public IP Address

While we could do the IP at the time we make the Virtual Network Gateway, we'll take care of it now to ensure it's provisioned prior to getting to that step and to discuss the IP details.

1. Navigate to "Public IP addresses".
2. Click "Add" and populate the following:
• Name: Select a name leveraging consistent naming standards.
• IP address assignment: Select "Dynamic". I know what you're saying.. you're saying "but Toby, I'm not saying anything", and what I'm saying is it seems this should be static. Unfortunately if we make a static IP we'll be greeted later with the following:
  
  

  

  Why Azure, WHY?!

  
  Now I've been running a tunnel straight for almost a month thus far and my dynamic IP has not shifted on me; I suspect it will behave the same as IPs for other resources and stay static so long as it is used. If this does change, you'll need to change the info in the Phase 1 and 2 setup of the tunnel on the pfSense side as outlined below. For the record, as of the writing of this article the pricing of IPs in Azure is a bit odd; dynamic IPs and static IPs beyond the first 5 in any region are charged the same (pretty trivial), while the first 5 static in a region are free. See here for more info.
• Idle Timeout: The default of 4 minutes should be fine here.
• DNS Name Label: Optionally, specify a DNS alias here, though we will not reference it again in this guide as I'm not addressing DNS issues associated with IPsec at this time.
• Subscription: Select your subscription.
• Resource Group: Click the resource group we created in the last step.
• Location: The IP is our IPsec target, so select a location close to your local network connection. The Azure Speed Test comes in quite handy here.





3. Click "Create". This provisioning will take a few minutes minutes as Azure re-arranges its SDN infrastructure to give you an IP.





What a successful deployment looks like!

Virtual Network/Subnet/Gateway Subnet

A "Virtual Network" is a network space within Azure that you can carve up and protect (firewall) to suit your needs. We're required to make one subnet, and we'll create our "gateway subnet" (landing point) as well. If this is your first foray into virtual networks on Azure you may want to take a step back and consider your design before proceeding. Oh, you're back already? Let's go.

1. Navigate to "Virtual Networks".





2. Click "Add" and supply the following:
• Name: Type a name for your Virtual Network; you should follow the naming standards as discussed above.
• Address Space: This is the overall space for your logical network within Azure. You can create more granular subnets within this space at any time, so erring on the side of a large subnet would be wise. If you're unsure, use 10.1.0.0/16.
• Subnet Name: You're required to create one subnet within your virtual network off the bat. You need to name it here and ensure you use a consistent and meaningful naming standard.
• Subnet Address Range: Specify a subnet range within your virtual network. This won't be used by our IPsec connection directly, but we will use it later as a target for testing. If unsure, use 10.1.10.0/24.
• Subscription: Select your desired subscription.
• Resource Group: Select "Use Existing" and select the resource group we created earlier.
• Location: Select the same location used for the IP above. 





3. After the Virtual Network has been created (use the refresh key if necessary), click it to navigate to the next pane, and then click "Subnets".





4. On the next pane, click "+ Gateway Subnet". And specify a subnet in "Address Range". This subnet needs to be different than the one we created earlier and should not be used for non-network resources, but rather as an ingress point to your Virtual Network. If unsure, use 10.1.0.0/24.

Virtual Network Gateway

The "Virtual Network Gateway" is our configuration element that facilitates the IPsec tunnel. Microsoft refers to this as a "VPN" gateway (as opposed to Express Route). There are three different VPN gateway SKUs; we'll be doing the "Standard" offering (of Basic, Standard, High-Performance). It's worth having a read about the differences here.

1. Navigate to "Virtual Network Gateways".





2. Click "Add" and supply the following:
• Name: Again, follow consistent naming standards.
• Gateway Type: Select "VPN".
• VPN type: Select "Route-Based" (packets routed by routing table) in this case; it would be advisable to familiarize yourself with the difference between route and policy here. Note that policy requires IKEv1, so if you need to use it note the settings will be quite a bit different.
• SKU: Update 1/2018: The SKU selection is now VpnGw<x> or Basic. Note you cannot change a basic VNG to the higher tier (VpnGwX) or vice versa at a later time. For more information see this article.
• Virtual Network: Select the virtual network we created in the last step.
• Public IP address: Select the IP address we created earlier.





3. Click "Create".

Note: This step may take up to 45 minutes to complete provisioning. I've tracked 8 of these and it's averaging almost 40 minutes per regardless of if you pre-provision the IP or not. You may want to consider skipping ahead to the pfSense section for a bit and coming back here.

Local Network Gateway/Connection

A Local Network Gateway is the specification of our local IP and networks you would like to route over the tunnel. 

This actually works fine with a dynamic IP if that is your scenario, but we'll cover the details of that later.

1. Navigate to "Local Network Gateways".





2. Click "Add" and supply the following:
• Name: Naming? Standards? Consistent? Yeah!
• IP Address: Enter the public IP address of your device that will instantiate the tunnel.
• Address Space: This is where you enter the CIDR notation of the local networks you would like to route over the tunnel... for example, if you would like to route 192.168.1.x over the tunnel, then enter "192.168.1.0/24"
• Subscription: Enter your desired subscription.
• Resource Group: Select our resource group we created above.
• Location: For consistency, select the same location as you have selected above.
• Update 1/2018: You can configure BGP settings here now as well, cool eh?





3. Click "Create".
4. After provisioning, (you may need to hit "refresh) click your newly created Local Network Gateway and click "Connections".





5. On the newly expanded pane, click "Add" and supply the following:
• Name: You know the drill by now.
• Connection type: This should be fixed to "Site to Site (IPsec)"
• Virtual Network Gateway: Enter the Virtual Network Gateway we entered in the step above.
• Shared Key: Specify a unique, randomly generated passphrase comprised of alphanumeric characters. Some devices have issues with special characters, hence the omission of. I recommend using at least 30 characters; since it has no impact on tunnel performance I personally use at least 60 characters for each key. You'll need to specify this key on your local side as well.
• Subscription: This should be hard coded to the same subscription as the LNG.
• Resource Group: This also should be locked to the same resource group as the LNG.
• Location: Locked to that of the LNG.





6. Click "OK".

Configure pfSense

Now we'll set up the IPsec initiator connection on your pfSense firewall(s).

Phase 1 Setup

1. Login to the firewall and navigate to "VPN->IPsec"
2. Click "Add" and specify the following:
• Key Exchange Version: Auto
• Internet Protocol: IPv4
• Interface: Select the WAN interface from which you would like to instantiate the connection
• Remote Gateway: Enter the Azure public IP address created in the "Public IP Address" section above
• Description: Whatever you would like; maybe troll your firewall team with a message here for fun times.
• Authentication Method: Mutual PSK
• Negotiation Mode: Main Note: Do not use "Aggressive" mode as the hash of the PSK is sent over the internet in clear text.
• My Identifier: If the WAN interface selected above holds your public IP address, you can select "My IP Address". If that interface lies behind another edge device that holds the public IP, you'll need to select "IP Address" and specify your external IP.
• Peer Identifier: Peer IP Address
• Pre-Shared Key: Enter the same Pre-Shared Key used in the Azure connection specification above.
• Encryption Algorithm: The strongest available in Azure is AES 256 bit, so preferably specify that. For more information on supported features in Azure, see the References section below.
• Hashing Algorithm: The best we can do here is SHA256, so let's go with that.
• DH Group: 2(1024 bit)
• Lifetime (seconds): 10800
• Disable Rekey: Unchecked
• Responder Only: Unchecked
• NAT Traversal: Auto (Even in NAT scenarios Auto usually works)
• Dead Peer Detection: Checked
• Delay: 10
• Max Failures: 5





3. Click "Save" to return to the "VPN->IPsec" menu.
4. Since we don't want to use this yet, click "Disable" in front of the new tunnel definition and then "Apply Changes".

Phase 2 Setup

1. Under our newly created tunnel definition, click "Show Phase 2 Entries"
2. Click "Add P2" and supply the following information:
• Disabled: Unchecked
• Mode: Tunnel IPv4
• Local Network: Select "Network" and specify the same network range(s) that you specified during the set up of the local network gateway on Azure using CIDR notation, i.e. 192.168.1.0/24. This specifies which local network(s) you would like to route through the tunnel.
• NAT/BINAT translation: None  ; Note: even in scenarios where your pfSense device is using NAT behind an upstream router, this should not be necessary. NAT-T will take care of that scenario.
• Remote Network: Select "Network" and specify the same network range(s) that you specified during the set up of the target virtual network in Azure using CIDR notation, i.e. 10.1.0.0/16. This specifies the remote network(s) present in Azure.
• Description: Put something here to help you remember what all this fun stuff is about.
• Protocol: ESP
• Encryption Algorithms: Check only "AES" and "256 bits".
• Hash Algorithms: Unfortunately Azure only supports "SHA1" at this time. Update 1/2017: SHA256 supported now, use that!
• PFS Key Group: Azure documentation states that PFS groups are only supported when Azure acts as responder, and in this case it is being set up as the initiator. Oddly, I've actually had luck specifying DH Group 14, but there is no guarantee that will work. I'm going to stick with it but for this by the book exercise you'll need to select "off". Note: Because of this setting and the prior Hash Algorithm setting, I do not consider this tunnel secure against state-level or similarly equipped actors. If that is a concern you may wish to investigate alternatives. In less extreme cases, however, this can be considered relatively secure. Update 1/2017: The compatibility has been improved here as well; match your Encryption/Auth with the right group using the table here.
• Lifetime: 3600
• Automatically ping host: blank





3. Click "Save".  

Note: Depending on your configuration it may be necessary to navigate to "VPN->IPsec->Advanced Settings" and check "Enable Maximum MSS", then specify 1350. If you get packet loss with large packets this setting may be needed.

Firewall Rules

Now that our tunnel is set up we have to create local firewall rules that allow for traffic to pass. First we'll create a network alias for the Azure side network and then we'll make a rule to allow out Azure based traffic to pass here.

1. Navigate to "Firewall->Aliases"
2. Click "Add" and supply the following:
• Name: Supply something that explains this network is to represent the Azure side of the tunnel; only alphanumeric and "_" are allowed.
• Description: Enter full description here; there are no special character limitations.
• Type: "Network(s)"
• Network(s): Enter the CIDR notation of the network you created for your Virtual Network in Azure. If you followed the example addresses in this article, that would be 10.1.0.0/16.
3. Click "Save" and then "Apply Changes".
4. Navigate to "Firewall->Rules->IPsec".
5. Click "Add -^" and supply the following:
• Action: "Pass"
• Disable this rule: Unchecked
• Interface: "IPsec"
• Address Family: "IPv4"
• Protocol: "Any"   Discussion: Feel free to limit the traffic that goes through the tunnel if you like. In this example I'm allowing all traffic through.
• Source: "Single host or alias" and then specify the Azure network alias you created in step 2.
• Destination: This needs to be the local network(s) to which you would like to allow traffic. You can either do "network" with a CIDR notation or specify the entire network represented by an interface on the firewall. Note: if you have multiple networks you'll need a rule for each, so repeat the last couple steps for each.
• Log: Unchecked; keep in mind that should you need to troubleshoot temporarily logging traffic using this rule can be very useful.
• Description: It's a description, so let's do that!
• No advanced options necessary unless you would like to do so.
6. Click "Save" and then "Apply Changes".

As long as you have a blanket egress traffic rule we should now be able to route traffic over the tunnel. If you do not I expect you are aware of how to make a more specific rule to suit your needs.

A Note on NAT-T and Upstream Routers

If your pfSense device is behind another upstream router, you may need some changes to facilitate the port switchover after initialization. If this matches your configuration, consider that you may need the following on the upstream router:

• A firewall rule that allows UDP port 4500 into your pfSense device(s).
• A NAT port mapping rule that forwards UDP port 4500 to your pfSense device(s).

Try without first; some devices are aware enough of the switch to 4500 to perform the transition without rules, but if it does not work consult the documentation for the device in question.

Enable and Test

There are several ways to test our connection; in this case I'll be pinging a VM host in Azure assigned to the same virtual network that this tunnel is connecting to. We won't go through the provisioning of that; should you need to refer to this basic guide and ensure you place the VM in your target virtual network and initially created subnet (10.1.10.x in the example above).

We're about to go into a tunnel... a long one.

Preparing Your Target

• Ensure your VM is up and provisioned in the correct target virtual network.
• Since you can't put anything in the gateway subnet (correctly) this would be a good opportunity to put the VM in the subnet you were forced to create when creating the virtual network in the first place. Check/change VM->Network interfaces->Details->Settings->IP Configurations
• Get the private IP address from VM->Network interfaces. It should be 10.1.10.x if you're following the example addresses in this article.
• Make sure your VM is pingable! If you have instituted Network Security Groups that would inhibit access you'll need to modify them, though this should work by default since we're tunneled in. Make sure the firewall on the VM allows for incoming ICMP requests as well; on Win 2012 and higher set-netfirewallrule -DisplayName "File and Printer Sharing (Echo Request - ICMPv4-In)" -Enabled True will take care of you.

Bring Up The Tunnel

1. In the pfSense interface, navigate to VPN->IPsec.
2. In front of our new tunnel, click "Enable" then "Apply" toward the top.
3. Check tunnel status under Status->IPsec. The tunnel should come up automatically in about a minute. If there is trouble you can check the Status->System Logs->IPsec section for more details.

Check Tunnel Status in Azure & Ping Dat VM!

For this portion we'll use PowerShell; ensure you have the Azure ARM cmdlets installed. If not, give install-module AzureRM a shot from an elevated PowerShell prompt.

1. Login to your account: Login-AzureRmAccount
2. Look at your subscriptions and grab the name of the target sub: Get-AzureRmSubscription
3. Change to your correct subscription: Select-AzureRmSubscription -SubscriptionName <subscription name>
4. Check the status: Get-AzureRmVirtualNetworkGatewayConnection -name <Local Gateway Connection> -ResourceGroupName <Name of Resourcegroup to which it belongs>
5. On the output pane, check the "ConnectionStatus" property. It should be "Connected".

The Get-AzureRmVirtualNetworkGatewayConnection has a series of other interesting properties as well, including EgressBytesTransferred and IngressBytesTransferred.

Now proceed to ping your VM by the private IP listed in Azure. As long as everything is configured correctly you should receive a response!

Cost

VPN Tunnels are subject to a costs from a few different categories:

• VPN Gateway Pricing: This is an hourly cost incurred while the tunnel is available, not necessarily used. This means once it's provisioned you will incur charges at the hourly rate. As of the writing the standard performance level that we'll be using is billed at $0.19/hr in the US. If you have multiple Virtual Networks you will also be subject to a fee for outgoing traffic destined for another VNet. This rate depends on the zone and varies between $.035 and $.16 per GB. Data outbound to your site is charged at the standard data transfer rates (below) and inbound data is free.  Update 1/2017: Updated pricing for the new tiers can be found here.
  
• Data Transfer Rates: This depends on your level of utilization. The first 5GB of outgoing/month is free and the prices are set on a curve thereafter.
  
• Virtual Network Pricing: VNets are free; you can have up to 50 VNets per subscription across all regions.
  
• IP Addresses: You'll be using at least one IP address. The first 5 static in a given region are free, additional and dynamic are charged at a rate of $.004/hr.

Overall the cost of a "standard" class data tunnel each month for a single IP address, no additional support, and without including outgoing bandwidth, is about $140/month. 

Note: Costs as of 10/26/2016, subject to change. Up to date pricing information is available here.

Dynamic IP? Changing Your IP Address

There is no reason that this IPsec tunnel will not work without a dnymic IP, but each time the IP changes you'll need to take a series of steps to restore tunnel functionality. These are:

1. In Azure, the local network gateway specifies your IP, change it under "Local network gateway-><NAME>->Configuration->IP address".
2. In pfSense, the Phase 1 tunnel definition under "My identifier" needs to reflect your current external IP address.
3. If there are any implications on upstream  routers you'll need to handle that as well.

After taking care of these you will need to restart the tunnel. This could all be automated with PowerShell and SSH if you like, but I won't be covering that here.

Update 1/2017: FWIW, over the last year none of my clients have had their IP rotate for an active tunnel.

A Note on Effective Security

As mentioned earlier, this set up does have a couple security issues; the impact of which I would like to discuss briefly. Without an optimal security configuration, including the support of Perfect Forward Secrecy, this tunnel may not be strong enough to stand up to attacks of a state-sponsored actor over a long period of time. Because of that I cannot recommend this solution if your traffic may be subject to that level of attack, for example traffic facilitating substantial financial transaction activity. Update 1/2017: As noted above, this situation has improved with the support of PFS and SHA256 for authentication.

With that said, this tunnel is still (for better or worse) more secure than the configuration I have seen at many clients, and should be suitable for most traffic. It also performs very well; added latency between my modestly equipped pfSense devices and Azure is trivial.

For science!

References

Azure

Microsoft: Azure Virtual Network Overview
Microsoft: Azure Resource Manager Cmdlets (PowerShell)
Microsoft: Create a VNet with a Site-to-Site connection using the Azure portal
Microsoft: Create a VNet with a Site-to-Site connection using PowerShell
Steve Buchanan: Azure & RRAS Site to Site VPN Setup (Azure Resource Manager)
Microsoft: What is a Network Security Group?
Microsoft: VPN Gateway FAQ
Microsoft: About VPN Gateway
Microsoft: How to install and configure Azure PowerShell
Microsoft: About VPN Devices for Site-to-Site VPN Gateway Connections (Critical article; contains IPsec specs of Azure side)

pfSense

pfSense Doco: Routing internet traffic through a site-to-site IPsec tunnel
pfSense Doco: VPN Capability IPsec

IPsec

PFS RFC
strongSwan Wiki: Security recommendations
Johannes Webber: Considerations About IPsec Pre-Shared Keys
Cisco Support: How Does NAT-T Work With IPsec (Only needed if behind NAT)

PowerShell Networking Cheat Sheet

Foreward

I haven't located a good cheat sheet for basic PowerShell commands to manage your Network Card/IP stack, so I thought I should make one. If you like this please share it with your mom because I'm sure she's been waiting to set a static IP address via PowerShell for some time. Also you should call her more.

My campaign against stock photography continues.

Assumptions

• Windows 2012/Windows 8 or higher
• Administrator access to the machine in question
• Powershell ran as administrator on the machine in question

CMDLet List:

Most of the commands used to manipulate IP settings can be found by typing Get-Command -Module NetTCPIP

PS C:\WINDOWS\system32> Get-Command -Module NetTCPIP

CommandType     Name                                               ModuleName
-----------     ----                                               ----------
Function        Find-NetRoute                                      NetTCPIP
Function        Get-NetCompartment                                 NetTCPIP
Function        Get-NetIPAddress                                   NetTCPIP
Function        Get-NetIPConfiguration                             NetTCPIP
Function        Get-NetIPInterface                                 NetTCPIP
Function        Get-NetIPv4Protocol                                NetTCPIP
Function        Get-NetIPv6Protocol                                NetTCPIP
Function        Get-NetNeighbor                                    NetTCPIP
Function        Get-NetOffloadGlobalSetting                        NetTCPIP
Function        Get-NetPrefixPolicy                                NetTCPIP
Function        Get-NetRoute                                       NetTCPIP
Function        Get-NetTCPConnection                               NetTCPIP
Function        Get-NetTCPSetting                                  NetTCPIP
Function        Get-NetTransportFilter                             NetTCPIP
Function        Get-NetUDPEndpoint                                 NetTCPIP
Function        Get-NetUDPSetting                                  NetTCPIP
Function        New-NetIPAddress                                   NetTCPIP
Function        New-NetNeighbor                                    NetTCPIP
Function        New-NetRoute                                       NetTCPIP
Function        New-NetTransportFilter                             NetTCPIP
Function        Remove-NetIPAddress                                NetTCPIP
Function        Remove-NetNeighbor                                 NetTCPIP
Function        Remove-NetRoute                                    NetTCPIP
Function        Remove-NetTransportFilter                          NetTCPIP
Function        Set-NetIPAddress                                   NetTCPIP
Function        Set-NetIPInterface                                 NetTCPIP
Function        Set-NetIPv4Protocol                                NetTCPIP
Function        Set-NetIPv6Protocol                                NetTCPIP
Function        Set-NetNeighbor                                    NetTCPIP
Function        Set-NetOffloadGlobalSetting                        NetTCPIP
Function        Set-NetRoute                                       NetTCPIP
Function        Set-NetTCPSetting                                  NetTCPIP
Function        Set-NetUDPSetting                                  NetTCPIP
Function        Test-NetConnection                                 NetTCPIP

To find out more about any given command, type Get-Help <cmdlet name>

Common Tasks

Here are walkthroughs of some of the more common tasks you may want to perform.

List Network Adapters

Gets a list of all adapters in the machine; you'll need to know your adapter name or index # (both listed) for some of the commands below.

Get-NetAdapter

Change an Adapter Friendly Name

You may want to consider changing the friendly name of the adapter you intend to manipulate. By giving it shorter, more meaningful name you'll have an easier time going forward. Use the old name you got from the last command. Syntax is Rename-NetAdapter -Name "<Current Name>" -NewName <"New Name">

Rename-NetAdapter -Name "Local Area Connection" -NewName WiFi

Get the Current IP Address

Gets all IPv4 addresses on the machine; you'll almost always have multiple as your loopback interface (127.0.0.1) will be listed. Ignore that guy.

Get-NetIPAddress -AddressFamily ipv4

Optionally, you can specify -InterfaceAlias <friendly name> or -InterfaceIndex <index #> to limit the command to a single adapter.

Assign a Static IP Address to your Network Adapter

This command will set the one and only (overwriting what is there) IP address for the specified network adapter. You also can (and should) set the subnet mask with this command. The subnet mask is set via CIDR using the -PrefixLength; see the link for more info about CIDR, but if you're not familiar with CIDR it is likely that you want -PrefixLength 24 which translates to 255.255.255.0 meaning the first three octets are the network while the last is the host. Syntax is New-NetIPAddress -InterfaceAlias <name> -IPAddress <IP address> -PrefixLength <CIDR> -DefaultGateway <Gateway IP>  . You can substitute -InterfaceIndex <index #> for -InterfaceAlias .

New-NetIPAddress -InterfaceAlias WiFi -IPAddress 192.168.1.10 -PrefixLength 24 -DefaultGateway 192.168.1.1

Note: You will get an error if you already have a static IP address with a default gateway. To fix this problem see "Delete Existing Static IP" below and then try again.
Note2: We're not using "Set-NetIPAddress" here because it doesn't allow you to set a default gateway. BOOOO.

Set DNS Servers for your Adapter

To look up names you'll need to set DNS server(s). Syntax is Set-DNSClientServerAddress -InterfaceAlias <name> -ServerAddresses ("<IP Address 1","IP Address 2") . You can set as many DNS servers as you like. You can substitute -InterfaceIndex <index #> for -InterfaceAlias .

Set-DNSClientServerAddress –interfaceAlias WiFi –ServerAddresses (“192.168.1.5”,”192.168.1.6”)

Set a Default Gateway

It's generally easier to set the default gateway as part of the New-NetIPAddress command above, but if you want to set one separately see "Set a Static Route" below.

Delete Existing Static IP (to prep for a new)

This is a two step process; you need to delete the IP, then the gateway. No need to worry about the DNS servers here as it works to overwrite them with the command above. You will need to know the IP address you want to delete first; use get-netipaddress (above) to get it (write it down to use below if necessary). You'll then need to know the NextHop of the gateway. To get this, use the get-netroute command and write down the entry(ies) that have a nexthop of the gateway you intend to remove (see screenshot).

The syntax for these commands are
Remove-NetAddress <IPAddress> -Confirm:$False
Remove-NetRoute -NextHop <Gateway IPAddress> -Confirm:$False

Remove-NetAddress 192.168.1.10 -Confirm:$False
Remove-NetRoute -NextHop 192.168.1.1 -Confirm:$False

Note: If you have multiple routes set with that default gateway it will delete them all. If you haven't manually set routes, don't worry about it (you just have the one).

Set Your Adapter to Use DHCP

This is another two step process; first set the desired adapter IP/Gateway to DHCP then set the DNS servers to pull from DHCP as well.

The syntax for these commands are:
Set-NetIPInterface -InterfaceAlias <name> -Dhcp Enabled
Set-DNSClientServerAddress -InterfaceAlias <name> -ResetServerAddress
You can substitute -InterfaceIndex <index #> for -IterfaceAlias if you prefer.

Set-NetIPInterface -InterfaceAlias WiFi -Dhcp Enabled
Set-DNSClientServerAddress -InterfaceAlias Wifi -ResetServerAddress

Note: If you have a static gateway set you'll need to perform the second step "Remove-NetRoute" from the step above as well. 

Advanced Tasks

Here are walkthroughs of some of the more common tasks you may want to perform. My assumption here is that you know what you want to do so I won't be discussing the details of what each of these means.

Add/Delete a Static Route

Add: (use -RouteMetric to specify metric or -PolicyStore to control persistence through reboots)

New-NetRoute -DestinationPrefix 192.168.2.0/24 -InterfaceAlias WiFi -NextHop 192.168.2.1

Add default route:

New-NetRoute -DestinationPrefix 0.0.0.0/0 -InterfaceAlias WiFi -NextHop 192.168.2.1

Delete: (while this command is very specific you can be more generic; see above)

Remove-NetRoute -DestinationPrefix 192.168.2.0/24 -InterfaceAlias WiFi -NextHop 192.168.2.1

Test Network Connectivity (Ping)

Test-Connection replaces ping.exe. In addition to the ping functionality Test-Connection supports authentication (if firewall is set accordingly), multiple targets in a single command, running as a job, as well as more detailed returns.

Test-Connection myhost.mydomain.com

Assign a DNS Suffix

This is the domain under which your IP will be registered and under most circumstances will be used to append to hostname searches. Note this is per-adapter. You can substitute InterfaceIndex for InterfaceAlias if you like.

Set-DnsClient -InterfaceAlias WiFi -ConnectionSpecificSuffix mydomain.com

Assign an Additional IP Address to your NIC

If you want to add another IP (usually only applicable on a server)

New-NetIPAddress -InterfaceAlias Ethernet1 -IPAddress 192.168.1.101 -PrefixLength 24

References/More Information

TechNet: Net TCP/IP Cmdlets in Windows PowerShell
TechNet: DNS Client Cmdlets in Windows PowerShell
TechNet: Network Adapter Cmdlets

You did it, hug a puppy!

Setup and Tweak Your New Asus RT-AC66U or N66U Router! (partially OT)

Asus has been doing an increasingly impressive job in the "home" WiFi router market. With impressive performance approaching enterprise class routing capability and second-to-none Wifi performance, (for an unmanaged single unit) they're hard to beat for the enthusiast market. By using something like TomatoUSB firmware you can get many enterprise-class features. While I may write an article in the future on Tomato or DD-WRT tweaking, I'm going to go through the setup here using the new "Merlin" firmware. Eric Sauvageau, the author of the modified firmware, states of this:

"The primary goals of this project are to fix bugs, add a few basic features and tweaks to the original firmware. This firmware will try to remain as close as possible to the original firmware."

Sounds good to me. I've spent alot of time with Tomato and DD-WRT on my home network, and a change of pace might be nice. Also, you get the piece of mind that you're using mainly the manufacturers' code on this newer hardware.

Note: Some ideas covered in this article may apply to other consumer or enterprise level hardware.

Assumptions:

• You have purchased either a RT-AC66U or RT-N66U (Update 7/6/13: RT-AC56U now supported asw well)
• You have backed up, memorized, or otherwise, your old router settings
• You're comfortable with the basics; I'm not going to re-cover the manual 
• You have power and an internet connection. Setup will be easier and more reliable if you also have a house or apartment, which you should be inside of during this tutorial. 

Let's get to work:

1. Connect the router as described in the manual. If you have a DHCP server (other than the one on the router from your ISP) you'll either need to temporarily disable it or ensure it's assigning the 192.168.1.x range excluding .1.
2. Perform the initial "Quick Internet Setup" wizard
3. After/if it prompts you to update firmware, go ahead and do so.
4. If desired, (and some of my steps will assume this is done) download the "Merlin" firmware from here. In the interface click "Administration->Firmware Upgrade" and specify the path to the trx file. 
5. Now that we've upgraded, let's highlight important setup steps. I'm not going to cover the specifics of your environment, just things I recommend you pay attention to. First, navigate to "Wireless->WPS"  and set it to "OFF". Most implementations of WPS are NOT secure at all. For more information, see: This episode of the wonderful Security Now! podcast or this lifehacker article. There are many ways to get a complex WiFi key to nearly any device securely.

6. Navigate to "Wireless->Professional" and check the "Tx Power adjustment" and reduce it if possible. (Some experimentation required) Make sure you use the dropdown and do both 2.4ghz and 5ghz. Lowering your broadcast power will slightly shorten the range so you aren't broadcasting to your neighbors (polite) and may lengthen your hardware life. (See effect @ "Tools->Radios Temperature")
7. If you disabled the DHCP server, make sure you go to "LAN->DHCP Server->Log DHCP Queries" and hit "Disable".
8. To log stats, insert a USB thumb drive. It can be tiny and slow if you want. Navigate to "System Log->General Log" hit "Refresh". Copy the contents down and search them for the mount messages. In my case, the only message was "Jan  3 18:47:16 hotplug[1032]: USB vfat fs at /dev/sda mounted on /tmp/mnt/1GB", and that corresponds to @ /mnt/1GB for short since /mnt is a symlink to /tmp/mnt. Write this down. 
9. Navigate to "Tools->Other Settings" and set "Traffic history location" to "Custom location".
10. Set "Save history location" to the value you wrote down in step 8, select "Create or reset data files" (if this is the first time you have done this on this disk) and hit "Apply". 
11. (Added 1/12/13) Unless you're using STP with your other switches, etc. navigate to  "Lan->Switch Control" and set "Spanning-Tree Protocol" to "Off".  Cool that it supports STP though! (Update 10/11/2013: There has been some confusion on this, so to simplify: If you have more than one switch not including this Asus router, leave STP enabled. Otherwise, disable it. If you would like to better understand see this.)
12. (Added 1/20/13) If you aren't using IPv6 (yet), navigate to "IPv6"->"Auto Configuration Setting"->"Enable Router Advertisement" and set it to "Disable". 
13. (Added 1/20/13) Let's disable some other services that most people won't need. Unless you're using this router as a filesharing and/or DLNA device, do the following: Navigate to "USB Application"->"Media Server"->"Enable DLNA Media Server" and set it to "Off".
14. (Continued from #13) Navigate to "USB Application"->"Network Place/Samba Share"->"Disable Share" and click "OK" to confirm disabling the service.
15. (Continued from #13) Navigate to "USB Application"->"Miscellaneous Setting" and turn off "Force as Master Browser" and "Set as WINS Server" and click "Apply". 
16. (Added 2/4/2013) Recommended: Though I haven't tested (update 6/7, it's fine as of now, so if you need UPnP go ahead) to see if this firmware is impacted by the recent discovery that a substantial number of firmwares expose UPnP to the external interface of the router(!!) I still recommend turning it of if it's feasible. This means you'll have to forward ports manually, but if you're reading this I suspect you know how to do so anyhow. (If not, comment as such and perhaps I'll write an article about it) To disable the UPnP service navigate to "Advanced Settings->WAN->Internet Connection->Basic Config->Enable UPnP" and set it to "No" Update 5/27/2013:  How to forward ports: 
1. To forward ports, first determine what ports your service/application uses. While a search for "(Service) forward ports" generally returns the  ports needed for that service, you can also use something like portforward.com to look it up. Note that the port spaces of TCP and UDP protocols are separate, so make sure you get the protocol right and know that the port numbers can overlap. There are some pre-baked shortcuts in the Merlin/Asus firmware on the port forwarding page (listed in the next step) that will populate the ports for you; it may be worth checking those out to save some time.
2. After you determine your ports, open the manage interface of your Asus router and navigate to "Wan->Virtual Server/Port Forwarding"
3. Ensure "Enable Port Forwarding" is set to "Yes". 
4. Under "Port forwarding List" type the name of your application under "Service Name". This entry is cosmetic only and serves to identify this forward. 
5. Under "Port Range" enter the port(s) needed for this application. To open a range, separate the lowest port and the top port with a ":". For example, to open up ports 80 through 90 you would put "80:90". You can also put non-joining port ranges on the same rule by adding more ports after a comma. For example, to open ports 80 and 90, you would put "80,90".
6. On "Local IP" put the IP address of the machine hosting the service you would like to expose to the internet. If you don't know this address and you're (as default) using the DHCP server on the router you can find the address by going to the DHCP management on your router. 
7. On "Local Port" you generally want to put exactly what you put under "Port Range". The exception to this rule would be if you want to expose an internal port as a different port externally. 
8. Under "Protocol" select the proper protocol; TCP, UDP, or Both. Again, note that selecting "Both" would result in both sets of ports being opened. 
9. Click the plus icon "Add/Delete" and then click "Apply" at the bottom. Note that if your IP address changes then you'll need to update the rule. 






17. (Added 7/20/2013,Critical) A vulnerability has been discovered with the AICloud software. There is an official firmware that has been released that is reported but not confirmed to fix the problem, but that includes a very poor wifi driver so I would not recommend its use unless you have no 5ghz WiFi clients. The Merlin 372_30_2 build does not address this problem because Eric based it on a pre-release 372 version that didn't yet include the fix. (Confusing versioning by Asus..) If you don't run that new stock FW make sure you disable the AICloud! (AICloud->Smart Disk/Cloud Access) Update 7/24/13: There is a Merlin build that addresses this issue now available. See below for links.  Update 2/18/14: There have been stories about either this exploit and/or a potentially newly found exploit involving FTP and the AI cloud feature. I think the best advice at this time is from Eric (the author of the firmware).  The point: Because it is uncertain if this is entirely based on the old vulnerability, disable these features until the full nature of the exploit is disclosed and confirmed fixed.   Update 3/16/14: This should be fixed with the newest build (374.40) but frankly I would still leave them off.
18. (Added 11/3/2013) If you notice that your WiFi continues to loose connectivity and you need to reboot the router to fix it, try naming your 2.4Ghz and 5Ghz radios differently. I've noticed that some dual band devices (the iPad specifically) will bounce between frequency spectra and this will cause the Asus to become confused and stop relaying requests to the DHCP server correctly. To do so go to Wireless->General and dropdown between "2.4Ghz" and "5Ghz", ensuring they have different SSIDs so that your devices will target one of the two explicitly.

If I find any other important info I'll add it. Enjoy!

Note 1: If you enable "Tools->Other Settings->Enable advanced (per IP) monitoring" it will disable hardware acceleration. While you most likely won't notice this unless you've got an internet connection approaching 100Mbit, be aware that you may loose some performance for that functionality.

Note 2: Check out "USB Application-> 3G/4G"... very interesting stuff.

Note 3: I'm investigating an issue that results in WiFi being unable to communicate with the LAN ports. It manifests itself in the log as: Jan 11 17:05:23 kernel: eth1: received packet with  own address as source address . I'll post updates on this later.

Update 2/2/2013: Merlin posted a new beta build. Discussion, Changelog .

Update 2/23/2013: More new builds & bugs fixed! Release Thread and changelog.

Update 3/16/2013: Another new build! Release Thread, Changelog

Update 3/29/2013: Eric just uploaded a new beta build based on a beta release from Asus. A couple exciting changes here including new wireless driver and tools. Note that you'll need to re-add you WoL clients (if you had any) because Asus added a new WoL tool. Also, note this warning from Eric:
"New wireless driver. This new driver brings quite a few improvements over the older one. Note that if you experience any issue with this new driver, it is strongly recommended to revert back to factory defaults, and re-configuring your router. There are a few low-level changes, and some new default values that you won't pick up until you revert back to factory defaults."  Release Thread, Changelog, Download

Update 4/4/2013: It looks like some folks are having issues on the new build with the 5Ghz radio. There is quite a lively discussion going on and Eric has answered quite a few questions.

Update 7/6/2013: A new build has been released that introduces support for the RT-AC56U! Release Thread, Changelog, Download

Update 7/24/2013: Another new build, (3.0.0.4.372.31) this time fixing the AI Cloud security issue and introducing the Yandex DNS filtering service. Be wary though that Yandex is in Russia, so if you use this feature (off by default) it may noticeably slow internet browsing since it redirects all your DNS queries. Release Thread, Changelog, Download.


Update 10/3/2013: Eric has been hard at work on a new build(3.0.0.4.374.33) based on a new source that includes fixes to general performance, parental controls, and more. Note this warning from Merlin: 

"IMPORTANT:
Due to the SDK change on the RT-N66U, you *MUST* revert back to factory default and manually reconfigure your router if coming from an older firmware! The only exception is if you were previously running either the Pixie Dust release (3.0.0.4.374.32-sdk6), or a previous beta of 3.0.0.4.374.33 (except for the -sdk5 Beta, of course).

Asus also recommends doing the same for the other models, however feel free to try without doing so. It might work fine for most people, but be prepared to do a factory default reset + reconfiguration if you run into any odd issues.

And by "manually reconfigure", I really mean it. Reloading saved settings would totally nullify the action of resetting to factory defaults, since you will just end back to where you started, with all the same (possibly invalid) settings."

Release Thread, Changelog, Download.

Update 12/14/2013: New build! (3.0.0.4.374.35_4) GPL 374.339 (Time machine support for some models), Asus' OpenVPN implementation. (Note this is a total overhaul), Namecheap DDNS, and more.  Release Thread(With Changelog), Download.

Update 1/22/2014: New build! (3.0.0.4.374.38) GPL 374.2078, major driver/SDK changes. RT-N16 is not supported by this build. This is SDK6 only. In short, if you have issues with this build, particularily with wi-fi performance, fall back to an earlier build. That said, the feedback in the forum regarding this build has been great thus far. Note: in most situations, Eric does recommend resetting to factory defaults & manually re-configuring. Release Thread With Changelog, Download

Update 2/16/2014: New build, out for a bit. (3.0.0.4.374.39) Dumps SDK5 and adds a new parental control option to use DNS services to block category based URLs as well as bug fixes. Release Thread, Changelog, Download

Update 3/16/2014: New build: 374.40. Not stable for the RT-AC68U but fixes the RT-N16. DNSFilter enhanced along with IPv6 fixes. This build should also address the highly publicized security issues from last month, but I would still recommend highly against enabling FTP, "Cloud AI", or any other outward facing services on principal. Release Thread, Changelog, Download.

Update 6/6/2014: New build: 374.43. Another new release from Eric today, mostly bugfixes. One feature added; the ability to force a DDNS refresh after a configurable number of days. Release Thread, Changelog, Download. Also, SmallNetBuilder forum member "000111" (7?) had the great idea to start a donation thread for Eric. If you appreciate his efforts it's worth considering heading over to this thread and throwing him a few bucks for the effort.

Update 11/7/2014: New build: 376.48_1. Merge with Asus code 3.0.0.4.376_2769, Samba upgraded to 3.6.24, Miniupnpd to 1.9, Dropbear to 2014.66, OpenSSL 1.0.0o, SNMP enhanced, RT-AC68P support. Release Thread, Changelog ,Download. Also, Eric (Merlin) warns of a but that causes wifi issues. Quoting him: "Note: Previous firmwares (both Asuswrt-Merlin and stock Asus) suffered from a bug where some nvram settings might end up being corrupted, which can lead to the loss of the 2.4 or 5 GHz settings on the webui with newer firmwares. To fix the issue, either do a factory default reset, or run the following commands over SSH:

Code:
nvram set wl0_band=2
nvram set wl1_band=1
nvram commit

The actual bug was fixed both on my end and by Asus a few releases ago, however the corrupted setting will cause issues starting with newer firmware versions if not corrected."

Update 8/292015: There have been several new builds, the last of which was great, but this update is to address how to perform source based routing with Merlin/Busybox:

In my case I've got two different internet connections and I want to selectively route different machines through different internet gateways. To accomplish routing traffic based on the source, we'll use the ip rule and ip route commands.  First, make the rule:

ip rule add from [IP]/[CIDR] table [NAME]

where [IP] is the from addr or range, [CIDR] is the applicable CIDR bitmask, and [NAME] is a unique integer to call the route, i.e.

ip rule add from 10.0.0.1.22/32 table 10

then the custom route:

ip route add default via [Gateway IP] table [NAME] dev [ADAPTER]

where [Gateway IP] is the IP of the desired gateway, [NAME] is the same integer as referenced above, and [ADAPTER] is the NIC to which the rule applies, i.e.

ip route add default via 10.0.0.254 table 10 dev eth0

You can re-use the route for multiple rules if desired. To make these rules persistent you'll need to use user scripts.I use services-start with a 10 second sleep in the beginning. Have fun!