Azure automation with Logic App - passing variable in workflow

Similar to AWS Lambda, Azure Logic App can be used for automated workflow. However, clear documentation is harder to come by, with fewer working examples, and often lack of effective technical support.

In a workflow, it should be a common requirement to pass the output of one step to another step. The motivation to post this working solution, is there is no clear example that illustrates how exactly that is done. It should be learned in a few minutes, rather than hours of trial and error.

output from step 1

Using a simple two step workflow to illustrate, in step 1, we use an Azure Function App with a powershell script.  We can obtain a user email dynamically from Azure VM's user defined tag field.

$user_email = (Get-AzureRmVM -ResourceGroupName $resourceGroupName -Name $resourceName -ErrorAction $ErrorActionPreference -WarningAction $WarningPreference).Tags["user_email"]

More importantly, the obtained result needs to be sent to this rather odd "Out-File" structure. This is how variable can be passed in the workflow:

$result = $user_email | ConvertTo-Json
Out-File -Encoding Ascii -FilePath $res -inputObject $result

input to step 2

In a subsequent step, we can use the output of previous step, in this case, sending an email to VM's user per tag. This is best illustrated using the graphical interface of Logic App Designer:

Azure recognized a step generates an output, and make it available to be used for subsequent steps. The particular handle is shown as "Body" of Step 1 Function App, again, rather odd representation.

But it does work. And this simple mechanism is a much needed building block to construct complex features in a workflow.

Azure VPN - keeping tunnels up

As noted in the previous post, Azure’s “dynamic routing” option really refers to the dynamic establishment of VPN, not routing itself. There is a drawback with this option, a VPN tunnel will go down after a period of non-usage. It re-establishes automatically when new traffic passes through, but often with the consequence of dropping initial traffic (due to time needed to re-establish tunnel).

The disruption is due to the expiry of Security Association. A security association expires after the first of these lifetimes is reached: a "timed" lifetime and a "traffic-volume" lifetime. The default lifetimes are 3600 seconds (one hour) and 4,608,000 kilobytes (10 megabits per second for one hour per second for one hour).

Normally, when there is active traffic, a new security association is negotiated before the lifetime threshold of the existing security association is reached, to ensure that a new security association is ready for use when the old one expires.

If no traffic has passed through the tunnel during the entire life of the security association, a new security association is not negotiated when the lifetime expires. Instead, a new security association will be negotiated only when IPsec sees another packet that should be protected.

Therefore, for Azure “dynamic routing” VPN tunnel with sparse traffic, SA may expire after an hour, causing some traffic drop, which may impact user experience.

An obvious method to correct this issue is to set SA lifetime to higher values. For example, in Cisco IOS:

crypto ikev2 profile profile_xxx

set security-association lifetime kilobytes 4294967295

set security-association lifetime seconds 86400

Extending the SA lifetime works, but there is a better method, which is using IKEv2’s support for Dead Peer Detection (DPD). DPD is also configured under profile, for example, the following wil send DPD keepalive every 5 minute, if there is no incoming traffic, thus keeping tunnels up.

crypto ikev2 profile profile_xxx

 …

 dpd 500 100 on-demand

Please reference your specific vendor documentation such as this Cisco guide for more information on DPD.

Azure VPN – ACL confusion clarified

Azure currently only supports VPN connections with static routing. For such a simple set up, there is a surprising amount of confusion in documentation, and with vendor support. Given the lack of clarification found on the internet, this may help a few others.

Similar to AWS, during Azure VPN deployment, a sample configuration template can be downloaded, which can be modified to use on your own devices. For the route-based VPN configuration, the downloaded template, as well as those shown in official documentation, like this sample Azure VPN template, includes the definition of an ACL like this:

As a network engineer will notice, the ACL is defined, but never used. When asking Azure team, the answer got back was “the template has worked for other customers”. What they said turned out to be true, here are explanations for those who care for how things really work.

First, there are two different types of VPN connections, the table below compare the two side by side (for technical details refer to excellent illustrations by packetlife.net). Here we use the Route-based VPN, which Azure refers to as “Dynamic routing”. This, by the way, is an incorrect term. Because only the establishment of VPN is dynamic, no dynamic routing like BGP is supported with Azure at the moment. More importantly, Route-based VPN does not require an ACL, while Policy-based VPN does.

VPN type	Policy-based	Route-based
Microsoft term	static routing	dynamic routing
Require ACL	yes	no
Detailed explanation and configuration	http://packetlife.net/blog/2011/aug/15/policy-based-vs-route-based-vpns-part-1/	http://packetlife.net/blog/2011/aug/17/policy-based-vs-route-based-vpns-part-2/

For the Route-based VPN (or Azure’s “dynamic routing”) option, Microsoft’s documentation and Azure generated configuration includes an ACL but not using it, was the source of confusion. This also explains why it still works for other customers, the ACL is simply not used. Therefore, it is recommended that the ACL be removed, to avoid further confusion to your support and operational teams.

It’s puzzling such a basic mistake remains uncorrected for so long, any network engineers at Microsoft?