Creating an Azure VPN with a Draytek Router

Posted on 10 CommentsPosted in Azure, cloud, draytek, exchange, firewall, ipsec, vpn

The Microsoft Azure cloud operating system can be connected to your network by way of a virtual private network or VPN. Azure lists some supported devices and provides configuration scripts for them, but does not include the Draytek range of devices. Draytek devices are common in the small business market and for techy home users. This blog post will show how to configure a site to site VPN between your network and your Azure tenant using a Draytek 2920 router. Other Draytek routers will work as well, just the screenshots and instructions here are from that model of router.

Collecting required information

Before you start you need the following information to hand:

  • The IP subnets of your network. For the purposes of this blog these are and
  • The IP subnet that you wish to use in Azure. This needs to be different from the subnet(s) on your LAN. For the purpose of this blog this will be

Configuring Azure Networks

To configure your VPN login to your Azure tenant at and from the services area on the left click Networks near the bottom. Add a new network by clicking Create a virtual network or from the bottom toolbar clicking + New and from the options select Custom Create. Note that Quick Create will not create a valid solution as it will note create a VPN gateway.

Enter the name of the VPN network and enter a name for the affinity group that you need to create. You will place virtual machines into this affinity group so that they get an IP address valid for this network. I’m based in the UK, so I choose West Europe (i.e. Dublin) as the datacentre to use.


Click the right-hand arrow at the bottom of the screen and check Site to site VPN. You only need to add a DNS name and IP address (to an existing DNS server) on your LAN if your virtual machines need to use this DNS server to resolve on-premises resources. I will use Azure to do my name resolution, so will not enter them here.


Click the right-hand arrow at the bottom of the screen and enter a name for your LAN and your external IP address (not shown here). This needs to be a static IP address that is not NAT’ed, so in my case this will be the external IP address of the Draytek router. Also enter the address space(s) for your LAN.


Click the right-hand arrow at the bottom of the screen to go to page 4 of the wizard and select an address space that does not conflict with your LAN address spaces entered on the previous screen. In the picture below I have configured as the subnet with a /24 CIDR range. You can edit the values provided if they do not suit. For the subnets within this network, you need one or more subnets for the address space. My final aim for the Azure tenant is to host a multisite Exchange Server lab, so I will create four subnets within the address space. The first address space is going to be reserved for routing purposes back to my LAN. The routing subnet is configured by clicking the add gateway subnet button.


Click the tick mark and wait for the network to be created. Once created click the network name and then Dashboard.


You will see that the gateway is not created. To start the VPN gateway at Azure click the Create Gateway button on the lower black toolbar. Choose Static Routing and confirm the choice. In about 15 minutes time the status of the gateway will go blue and the VPN grey.


We can now move onto configuring the router on your LAN as Azure is now waiting for the connection to take place.

Configuring a Draytek Router to Connect to Azure

On the VPN page in Azure you will see the status of the connection showing the amount of data that has crossed the connection to date and the IP address that you need to connect your VPN tunnel to. Make a note of this IP address (redacted in the above picture) and also make a note of the Shared Key, this you can get from the Manged Key button on the toolbar. Copy this to your clipboard and navigate to your Draytek admin page.


Ensure that your router provides service for IPSec VPN’s and that this type of traffic is not being passed through the router to another device. This is available from VPN and Remote Access > Remote Access Control in the Draytek web admin pages.


Change to VPN and Remote Access > LAN to LAN and click an available LAN to LAN profile that is not being used. In section 1 give the profile a suitable name and enable it, disable Netbios naming packets from crossing the VPN and allow multicast if you will need it. Set the Call Direction to Dial-Out and check the Always on option if you require the connection to be up all the time. Scheduled connections are also possible.


Under Dial-Out Settings (section 2) ensure IPSec Tunnel is selected and the Server IP/Host Name for VPN matches the Gateway IP Address provided on the Azure management page. Under IKE Authentication ensure Pre-Shared Key is selected. Click the IKE Pre-Shared Key button and paste the pre-shared key from Azure.


Under IPSec Security Method select High (ESP) and ensure AES with Authentication is selected. Azure requires AES encryption. The Advanced options do not need changing as they are valid for Azure already.


Scroll down to section 5 (sections 3 and 4 do not need completing) and enter the network address space in use at Azure as the value for Remote Network IP and ensure the Remote Network Mask value is correct. This ensures that connections to this subnet are routed down this VPN tunnel. If you have multiple address spaces created at Azure then click the More button and add the rest of the Azure networks (not the individual subnets within the address space) if you added additional address spaces.


Save the VPN profile and navigate to VPN and Remote Access > Connection Management. In about 10 seconds you will see this page refresh and you should see the connection to Azure has been made.


Back on the Azure management console the VPN at the LAN side should be green and the Data In and Data Out values increasing. At the time of writing, an Azure VPN costs £1.44 per day and this does not include any network traffic across the link.


Creating Azure Virtual Machines on Your VPN

Ensure that your link is up by pinging the VPN endpoint at Azure. This will be the second IP address on the gateway subnet that was created earlier. In my example this is


Virtual machines in Azure will get an IP address from your VPN and will be directly reachable to and from your LAN if they are associated with the VPN network created when the VPN was created. To do this either create a virtual machine from the gallery option (not Quick Create) to make a new virtual machine from a template or one of your existing unused VHDs or images and set the region/affinity group to the VPN network.


Note that you cannot change the network that an existing machine is associated with – you need to delete the virtual machine (but without deleting the disks) and also delete the associated cloud service. Then you can make the VM again and choose My Disks from the gallery and select the VPN as the Region/Affinity Group/Virtual Network value.


That is it. You virtual machines will come online and be provisioned and get an IP address on your virtual network. To see the IP address click the virtual machine and view the dashboard. Note that shutting down the virtual machine will release the IP and you cannot assign static IP’s in Azure or the machine will not be reachable – all connectivity to Azure machines is via resolved names.

Secret NSA Listening Ports in Exchange Server 2013? Of Course Not…

Posted on Leave a commentPosted in 2013, Edge, exchange, firewall, IAmMEC, iis, networking, powershell, transport

But what do those extra ports in Exchange Server 2013 that are listening actually do.

If you bring up a command prompt on an Exchange Server 2013 machine and run netstat –ano | find “:25”. You will get back a list of IP addresses that are listening on any port starting 25. The last number on the line is the process ID for that listening port. So for Mailbox only role servers you are interested in the row that shows and for a multirole (CAS and Mailbox) server, the row that shows as shown:


Above you can see that process 21476 is listening on 2525 and as this is a multirole server this process ID will be EdgeTransport.exe – you can verify this in Task Manager if you want.

Repeat the netstat cmd, this time for the process ID you have selected: netstat –ano | find “xxxxx” where xxxxx is the process ID for EdgeTransport.exe, as shown:


You will now see that EdgeTransport.exe is listening in on a range of ports for both IPv4 and the same ports for IPv6. These ports are 25 or 2525, which is used by 2007 or 2010 Edge role servers, or by other 2007/2010 Hub Transport role servers or by other 2013 Mailbox role servers or by 2013 CAS role servers to send emails to this server via SMTP. Port 465 is the port that 2013 CAS servers proxy authenticated SMTP connections to that they receive on port 587 from mail clients. But what about port 29952 in my example (and on your servers a different port) which changes each time the service is restarted?

If you do netstat again just for this port you will see something like the following:


This shows that nothing is connected currently to these ports, and so they seem to be doing nothing. But if on a different Exchange 2013 server you do some viewing of the transport queues then these ports will start to show some activity.

On a different server in my environment I ran Get-Queue –Server remoteservername. If I do this on the local server, then nothing special happens as Exchange does not need to connect to these ports, but if it is run from a different server and I ask it to show the queue on the first server that we have been looking at above, then these ports become used:



Above we can see Exchange Management Shell on mail5 connecting to mail4 (the original server in this blog post). The second picture from mail4 shows that port 29952 have received a connection from the IPv6  address of mail5 and specifically from port 65172 on that remote server.

If I look finally at the second server in this exercise and see what process is connecting from port 65172 (and again, your ports will be different) I see that process 15156 is doing this (the process ID is the last column in the output)


Taking this process ID to Task Manager, I see process 15156 is the IIS Worker Process, which is the process that PowerShell connects to to do its work.


Therefore, the random and changing port that EdgeTransport.exe listens on is nothing to do with PRISM, but all to do with your management of remote queues.

Domain Secure and Edge Servers

Posted on Leave a commentPosted in 2007, 2010, 2013, certificates, cloud, exchange, firewall, smarthost, smtp, transport

I was asked a question recently on the Microsoft Certified Master course for Exchange 2010 and was told that the answer was not clearly written up on the internet. So I thought I would write this blog post. The question was based on the idea that Domain Secure worked from a Hub Transport server in the classroom lab but not when mail flow went via an Edge server.

Domain Secure is end to end security, it cannot have anything in the middle – i.e. it cannot go via an Exchange Edge server, an Exchange 2013 Frontend Server or a third party SMTP relay.

The SMTP client in the connection (the send connector host) needs to connect to the SMTP server (the receive connector host) and swap certificates and prove the other side is who the other side say they are – i.e. mutual authentication. Also the domains must match the TLS list in TransportConfig (TLSSendDomainSecureList and TLSReceiveDomainSecureList). Therefore anything in the middle will offer a different certificate and so Domain Secure fails.

If there is a middle party and you want to do mutual authentication (i.e. swap certs to prove who you are), with one party offering their cert and not the cert of the final recipient domain (i.e. or etc.) then use TLSAuthLevel and the DomainValidation option on the send connector (an SP1 addition to Exchange 2010). No green ticky ticky though.

Edge can do Domain Secure though. But Edge needs to be the starting point, i.e. the host of the send connector. So configure Domain Secure on the Edge (i.e. set the certificates and correct firewall settings) and ensure that the send connector for Domain Secure has the Edge server as the source. Ensure Edge Domain Secure receive connector is the target for inbound as well if you want it to work both ways. And of course you need working EdgeSync so hubs can deliver to Edge so that Edge can deliver emails for you.

Building An Exchange Unified Messaging Lab (Part 3)

Posted on 2 CommentsPosted in 2010, draytek, exchange, firewall, rtp, sip, unified messaging, voicemail

This blog is part of a series on creating a unified messaging lab for Microsoft Exchange Server. Configuring Unified Messaging was not as easy as I thought it would be and there was a lack of information that brought all the settings into one place, and a lot of incorrect information! The series started with Part 1 for the requirements and Part 2 for the initial configuration of AsteriskNOW and FreePBX.

Up until now the changes you have made have been pretty much the same for everyone. Sure, you have set an IP, keyboard and timezone that are different but everything else has been pretty much standard. Now we need to change some Asterisk configuration files to support Exchange Server Unified Messaging.

Configuring Asterisk for Internal and External Calls

As we have chosen to install FreePBX as well, we will edit the configuration files that FreePBX does not control. If you are doing your configuration without FreePBX installed there will be different files to change.

Before we make the changes though, you need to decide a few things. Some of these will be determined by your current environment. The first thing you will need to know is the number of digits in your dialplan. A dialplan is the internal extension number configuration at your office. For example if you dial 1xxx to reach one office and 2xxx to reach another then you have a four digit dialplan and sequences starting 1 and 2 are already reserved. In my lab I am going to use a four digit dialplan where 8xxx is going to be allocated to physical telephone handsets (extensions) and 8000 is going to be the number I call to listen to my voicemail (the Pilot Number) when I am using Exchange 2010 and 8500 when I am using Exchange 2013. Two numbers for voicemail allows me to use two different Exchange labs from one set of SIP phones.

Once you have picked your dialplan you can start to configure the various components of your PBX for your telephone network. These changes include forwarding your pilot number (8000 and 8500 in this blog) to Exchange and configure your telephone extensions.

In Asterisk we need to do these configuration changes by editing the config files. We can do this in a few different ways. We can edit the config files directly in the Linux console (using text editors such as vi), use WinSCP from a Windows PC if you don’t want to edit the files in Linux directly or use FreePBX for some of the changes. You must use FreePBX to change any file that has the FreePBX banner at the top of the config file.

SIP.Conf Changes for NAT and Exchange Server

Firstly, if you have a NAT’ed network you need to tell Asterisk your external IP address. Edit /etc/asterisk/sip_general_custom.conf to contain:

;externip needs to be your public IP

You also need to add the following to the same file:

context = default
bindport = 5060
bindaddr =
tcpbindaddr =
tcpenable = yes
promiscredir = yes

Amongst these changes some of them tell Asterisk to listen on TCP, bind to all IP addresses and listen on port 5060 for UDP. Exchange Server and Lync Server require TCP support from the IP PBX that they connect to and without these settings Asterisk will only do UDP. Asterisk 1.8 will only listen on 5060 for TCP and there is no config setting to change this. The bindport setting controls the listening port for UDP.

Notice that we changed the sip_general_custom.conf file and not sip.conf. If you did not have FreePBX installed you would make all your changes to Asterisk in the config files and so could edit sip.conf directly. FreePBX overwrites some config files with its settings whenever you click Apply Config in the web GUI. To avoid having your settings overwritten you need to make them to files that are referenced by include statements in the master file.

For this example, if you open sif.conf (in /etc/asterisk) then in the [general] section (where the above edits are needed) you will see #include sip_general_custom.conf. This tells Asterisk to load sip_general_custom.conf as part of sip.conf, and we know that sip_general_custom.conf will not be overwritten by FreePBX because it does not tell us this at the top of the file.

To determine the file that you need to make the change in for other config files open the master file that you need to edit (i.e. sip.conf in this example) and see if there is a FreePBX banner at the top of the file. If not, then edit the file as required. If there is a banner telling you not to make changes then look for the section that your change will be inside (for example in sip.conf above we made our initial changes in the [general] section) and locate the #include statement that follows that section. This statement tells Asterisk the name of additional config files to load and to consider as part of the master file that you are currently reading. Some of these include files contain the FreePBX banner as well but others don’t for example to make changes to the [general] section of sip.conf we will edit sip_general_custom.conf, the custom config file for the general section in the sip.conf file.

RTP.Conf Changes For Your Network

SIP is the protocol that is used to manage connections between the parties involved in the call. RTP is the protocol used to transfer the voice data. You need to edit /etc/asterisk/rtp.conf so that the rtpstart and rtpend values are suitable for your network.

For each call connections will be made to 5060 and two additional ports. These two additional ports need to be sequential, and the odd numbered port will carry RTP data (voice traffic) into your PBX and the even numbered port carries RTCP packets (data about the connection). Outbound SIP/RTP traffic is determined by settings on the other parties PBX, so you typically need to allow all outbound ports from your PBX.

Therefore you need to configure Asterisk to have a start and end range for RTP that is a minimum of two ports (for one concurrent call) and a max of the number of concurrent calls you can make to through your PBX. Your external firewall will need to be configured to publish all these ports to your IP PBX so don’t make the range too big – but equally you need two ports per concurrent call so don’t make the range too small.

The range will always be the higher of the max number of calls your SIP Trunk provider allows and the number of physical handsets you have (plus some overhead to allow for parked calls). So if you have a five call SIP trunk, ten staff members, and 12 handsets you would need to support at least 12 concurrent calls. Therefore configure RTP to start at 10010 and finish at 10034 (two ports for each of the twelve concurrent calls you can support). Then increase it a bit for your sanity!

Edit /etc/asterisk/rtp.conf so:

rtpend=your calculated value


Make sure your firewall forwards these ports to this PBX server and if you have other PBX servers ensure that you do not use the same port range. The following shows an example firewall configuration for this PBX. In the picture and in my config files I am using 5065 for SIP as I have two PBX’s and the other is using 5060.




Once we test calls to the outside world, if you start getting “one way traffic” (that is you can be heard but you cannot hear the caller or the reverse) then you need to check your firewall rules.


In Part 4 the fun will start. In this part we will configure a few telephone extensions so that we can make internal calls and then configure a SIP Trunk provider so we can make external calls. Part 5 will look at configuring Exchange Server 2010 and Part 6 the same, but for Exchange Server 2013. Part 7 will look at connecting these calls to your Exchange Server when we want to record a voicemail message.