My journey to automate vCloud Director with PowerShell – part #10: add a nat rule

Next step in my journey is a rather simple one. After i add the new firewall rule as shown in my last article, i immediately learned that only a firewall rule is not enough to let network traffic go throug an edge gateway. I also need a nat rule for adress translation.

Again i used the chrome developer tools to analyze what the cloud director UI does when adding a nat rule. From what i learned till now it were only three small steps:

use the network namespace of the REST API to get the nat configuration of the edge
Since there is no existing nat rule, simply add a new rule
write back the configuration to the network namespace of the REST API

The only part where i really had to do some research was the xml structure of the new nat rule. Since my newly created edge has no existing rule, i took the easy way and write the complete xml structure as one string in PowerShell.

$body = "<nat><version>1</version><natRules><natRule><ruleType>user</ruleType><action>snat</action><vnic>0</vnic><originalAddress>192.168.0.0/24</originalAddress><translatedAddress>10.0.0.55</translatedAddress><enabled>true</enabled><snatMatchDestinationAddress>any</snatMatchDestinationAddress><snatMatchDestinationPort>any</snatMatchDestinationPort></natRule></natRules><nat64Rules/></nat>"

For better understanding, the same xml structure as formatted code:

<nat>
   <version>1</version>
   <natRules>
      <natRule>
         <ruleType>user</ruleType>
         <action>snat</action>
         <vnic>0</vnic>
         <originalAddress>192.168.0.0/24</originalAddress>
         <translatedAddress>10.0.0.55</translatedAddress>
         <enabled>true</enabled>
         <snatMatchDestinationAddress>any</snatMatchDestinationAddress>
         <snatMatchDestinationPort>any</snatMatchDestinationPort>
      </natRule>
   </natRules>
   <nat64Rules/>
</nat>

To be honest, i cheated here a bit.
Every time you write a new nat configuration, you have to increment the “<version>” field. Since my newly created edge never had a configuration, i simply set it to “1”.

Since there are no new coding skills i learned here which i could explain i simply show you the final code:

# get a fresh copy of the edge object
$myedge = Get-EdgeGateway -Name $edgename

# build the url for the nsx rest api call
$myedgeid = $myedge.id.Split(":")[-1] # extract the guid from the object id
$url = "https://[DNS-NAME-OF-CLOUD-DIRECTOR]/network/edges/$myedgeid/nat/config"

# build the header for the api call
$header = @{
Accept='application/xml'
"content-type"='application/xml'
"x-vcloud-authorization"=$global:defaultciservers[0].SessionSecret
}

# build the body for the api call
# I cheated here a bit. Since the edge is newly created it has no nat rule.
# Therefore i can simply put this string as the first ever written config. Therefore version field is "1".
# If there are previous configurations you should first read the version, make the changes and increment the version before making the REST API call.
$body = "<nat><version>1</version><natRules><natRule><ruleType>user</ruleType><action>snat</action><vnic>0</vnic><originalAddress>192.168.0.0/24</originalAddress><translatedAddress>10.0.0.55</translatedAddress><enabled>true</enabled><snatMatchDestinationAddress>any</snatMatchDestinationAddress><snatMatchDestinationPort>any</snatMatchDestinationPort></natRule></natRules><nat64Rules/></nat>"


# execute call
$result = Invoke-RestMethod -Uri $url -Method put -Headers $header -Body $body

Next article in this series:
create a vm from template

Leave a Reply Cancel reply