Creating IPsets with VNS3 API

VNS3 supports IPsets in your firewall. This allows for very efficient firewall rule matching against blocks of IP ranges or ports. VNS3’s version of IPsets are called FWsets, but they are effectively the same. In this example we will walk through creating a FWset, creating a firewall rule that uses the FWset, and finally modifying our FWset.

Use Case - Segment Production and Dev Traffic

In this example we are going to create IPsets for a common use-case: seperating production and development traffic. Production network ranges will not have access to development network ranges and vice versa.

The production IP ranges will be 10.200.0.0/24 and 100.127.255.192/26. The development IP ranges will be 10.100.1.0/25 and 10.100.1.128/25. We want to prevent traffic between production and development networks. To do that we will do the following:

  1. Create FWsets for our Production and Development IP ranges
  2. Create firewall rules that drop traffic between Production and Development networks

Then to demonstrate updating an FWset we will do the following:

  1. Remove 100.127.255.192/26 from Production FWset
  2. Add 10.201.0.0/24 to Production FWset

Creating a FWset

The VNS3 API for FWsets closely mirrors the IPset syntax. Create an FWset with POST /firewall/fwsets. Each FWset must be named for use in firewall rules. Names must start with one of the following prefixes:

  • NETS_: Use this prefix for IP range rules. We will use this for our use case.
  • PORTS_: Use this prefix for port rules.
  • LIST_: Use this prefix for rules targeting IP:PORT URIs.

We will name our production FWset NETS_policy1_prod and our development FWset NETS_policy1_dev:

curl -X POST -u api:$apipassword \
    -H 'Content-Type:application/json' \
    -d '{"rules":"NETS_policy1_prod 10.200.0.0/24\n NETS_policy1_prod 100.127.255.192/26\n", "flush":"true"}' \
    https://$vns3host:8000/api/firewall/fwsets

With the python SDK:

from cohesivenet import VNS3Client, Configuration

vns3 = VNS3Client(
    Configuration(
        host="[VNS3-HOST]:8000",
        username=username,
        password=password
    )
)

response = vns3.firewall.post_create_firewall_fw_set(
    rules="NETS_policy1_prod 10.200.0.0/24\n NETS_policy1_prod 100.127.255.192/26\n"
)
print(response.json())

Successful response:

{
  "response": {
    "status": "ok",
    "rules": "NETS_policy1_prod 10.200.0.0/24\n NETS_policy1_prod 100.127.255.192/26\n"
  }
}

Now repeat with the development IP range with rules="NETS_policy1_dev 10.100.1.0/25\n NETS_policy1_dev 10.100.1.128/25\n. A GET /firewall/fwsets should return the following:

curl -X GET -u api:$apipassword https://$vns3host:8000/api/firewall/fwsets
{
  "response": [
    [
      "NETS_policy1_prod 10.200.0.0/24",
      "NETS_policy1_prod 100.127.255.192/26"
    ],
    [
      "NETS_policy1_dev 10.100.1.0/25",
      "NETS_policy1_dev 10.100.1.128/25"
    ]
  ]
}

Creating firewall rules

Now we create firewall rules dropping all traffic between the production and development FWsets.

First lets drop all traffic from development to production:

# Drop all incoming traffic destined for prod
curl -k -X POST -u api:$apipassword \
    -d '{"rule":"INPUT_CUST -m set --set NETS_policy1_dev src -m set --set NETS_policy1_prod dst -j DROP"}' \
    -H 'Content-Type: application/json' \
    https://$vns3host:8000/api/firewall/rules

# Drop all outgoing traffic destined for prod from dev
curl -k -X POST -u api:$apipassword \
    -d '{"rule":"OUTPUT_CUST -m set --set NETS_policy1_dev src -m set --set NETS_policy1_prod dst -j DROP"}' \
    -H 'Content-Type: application/json' \
    https://$vns3host:8000/api/firewall/rules

# Drop all forwarded traffic destined for prod from dev
curl -k -X POST -u api:$apipassword \
    -d '{"rule":"FORWARD_CUST -m set --set NETS_policy1_dev src -m set --set NETS_policy1_prod dst -j DROP"}' \
    -H 'Content-Type: application/json' \
    https://$vns3host:8000/api/firewall/rules

A successful response for each rule will look like:

{
  "response": {
    "status": "submitted",
    "rule": "INPUT_CUST -m set --set NETS_policy1_dev src -m set --set NETS_policy1_prod dst -j DROP",
    "token": "15911958458874_615891310013750682624479834085854066814065980878"
  }
}

Finally we need to create firewall rules dropping all traffic destined for development from production. Can you construct these rules? The INPUT_CUST rule will look like this: INPUT_CUST -m set --set NETS_policy1_prod src -m set --set NETS_policy1_dev dst -j DROP. GET /firewall/rules should contain your 6 rules.

Creating firewall rules with the python SDK:

vns3.firewall.post_create_firewall_rule(
    rule="INPUT_CUST -m set --set NETS_policy1_dev src -m set --set NETS_policy1_prod dst -j DROP"
)

Updating FWsets

You can update FWsets with the DELETE /firewall/fwsets and POST /firewall/fwsets. Currently VNS3 does not support appending single FWset rules to an FWset. Instead, the POST will overwrite the FWset by name.

Removing 100.127.255.192/26 from Production FWset:

curl -k -X DELETE -u api:$apipassword \
    -H 'Content-Type:application/json' \
    -d '{"rules": "NETS_policy1_prod 100.127.255.192/26"}' \
    https://$vns3host:8000/api/firewall/fwsets

Response:

{
  "response": {
    "status": "finished_ok"
  }
}
Tip: VNS3 also supports removing entire FWsets by name with the "name" parameter: '{"name": "NETS_policy1_prod"}'

Adding a new IP range such as 10.201.0.0/24 to production FWset requires a POST create for the entire FWset:

curl -X POST -u api:$apipassword \
    -H 'Content-Type:application/json' \
    -d '{"rules":"NETS_policy1_prod 10.200.0.0/24\n NETS_policy1_prod 10.201.0.0/24\n", "flush":"true"}' \
    https://$vns3host:8000/api/firewall/fwsets

Putting it all together

VNS3 provides a straightforward API on top of the very powerful IPset functionality for segmenting your network at scale. Here we demonstrated how to segment your production and development traffic to improve production stability and security.

Any questions on how to automate your network? Email us at support@cohesive.net or open a ticket directly on our support site.