Anouncement: Configuring VyOS' centrally via semantic API

As i have got now official “go” from my boss i want to announce our VyOS 1.3 HTTP-based deployment backend.

The tool has currently no name - internal name is “routingwebapp”. It provides an REST API for several semantic parts of VyOS configs, especially Firewalls and Ruleset generation, Basic Network Interface configuration. It works by diffing a running config and a generated one and pushes commands against the 1.3 HTTP API. Technically it is based on a combination of Django(restframework), Celery and a message broker like RabbitMQ.

  • The good: This backend will be open source, we are currently evaluating which OSI approved licenses do match best.
  • The bad: I have to remove references to our internal infrastructure before i can open the source, this will take a bit time, don’t ask for ETA (as always in these contexts).
  • The ugly: It’s alpha, no warranty, it’s likely there will be some breaking changes in the API. There is currently nearly no documentation and that’s horrible.

technical detail

Current list of entities, so you get an idea what our thoughts were while designing:

  • general
    • Router (+VyOS13Router): a router
    • StaticConfigSection (+VyOS13StaticConfigSection): a static configuration part of config for things that can’t be generated
    • Deployment: for tracking deployments via API
  • user management
    • Customer: a tenant or customer. Can be child of another → multi-tenancy-plus!
    • User: a user is always part of a customer (django’s user is not flexible enough to implement it)
    • LocalUserAuth: an authentication method for user, currently the only one
  • network management
    • Network: an IP Network
    • ManagedInterface (+ManagedVRRPInterface): an interface description
  • firewall management
    • Firewall: the firewall (consisting of rulesets)
    • RuleSet: a reusable set of rules
    • Rule: (abstract) definition of a rule
    • StandardRule: a simple rule just defining src, dst and dst service, should be enough for 90% of firewall rules
    • CustomRule: a complex rule, more like StaticConfigurationSection but in rule context rather than global context
    • AddressObject: (abstract) describing adresses
    • ServiceObject: (abstract) describing services
    • NetworkAddressObject: (-> AddressObject) links to an existing Network
    • CIDRAddressObject: (-> AddressObject) CIDR (in both protocols)
    • HostAddressObject: (-> AddressObject) a single IP (in both protocols)
    • ListAddressObject: (-> AddressObject) a list of other AddressObjects
    • SimpleServiceObject: (-> ServiceObject) a single port
    • RangeServiceObject: (-> ServiceObject) a portrange
    • ListServiceObject: (-> ServiceObject) a list of other ServiceObjects
  • change management (in preparation), think a bit like a non blocking session
    • ChangeSet: A set of changes
    • Change: A change on a single entity

Current state:

  • deploying firewalls using the semantical entities using the state in the database is possible
  • the API is working for CRUD of above items, currently without Sessions
  • triggering a deployment is currently only working in some cases (that’s where the change management comes in)
  • it’s quite monolithic
  • security is nearly not implemented (we will need it, but it’s simply currently nearly not implemented)

I’m working in a iterated way on this, so things are likely to change.

why i’m doing this?

Simply because my company needs it. The company does hosting in a B2B context usually providing also networks to customers for more flexibility.

I’m a bit sorry for doing redundant work to @robertoberto. There was a long time no reaction, so i had to start our own thing because managing our routers in current way is not scalable. Our work does not intend to make his work obsolete, it’s simply a different context and more GUI centric and without API:

Maybe in future we can combine things. As we need especially the central configuration management and want to integrate it in our existing web portal, it’s unlikely we will provide a generic GUI for this backend.

I’ll release the link to the code in this topic, as soon it’s ready.


Hi wornet-mwo I am waiting for definitions about new VyOS API Yuriy Andamasov bring us in
The future of VyOS, part 2: the local GUI and the controller to think about future of VyControl

Your project will help a lot in this rethink, maybe we can work together.

1 Like

Call it, “Omega One” :wink:

@robertoberto See my question and the answer there:

Here you go with “VyCinity”:

Very Alpha! Next activity in this repository is expected in august.

1 Like

whoops! i missed this one :slight_smile:

Wouldn’t it make more sense to work with @robertoberto to incorporate it into VyCenter?

This depends what you want to do. First of all, @robertoberto 's solution is relatively GUI centric and an API is not planned first. However, we will maintain shared instances (so we need multitenancy out of the box), which is something i did not see in his solution.

So i need to work further on my solution (and invest much more time), hopefully the GUI of vycenter can be used in future together with vycinity (where we will never publish a standalone GUI as we will integrate it into other webservices). I’m open to collaborate.

1 Like

it would be nice to see where both projects go! i have a firewall i can test with. if you need anything done, i’m willing to help. though not much of a coder (a bit of Golang and Ruby) i did recently started to work at a new MSSP who looks into developing a “managed firewall service” so i can deliver a lot of input on that part :slight_smile:

We looked into OPNSense first, they have a way of managing multiple firewalls from one console, their licencing is pretty hefty. (relatively speaking for the market we target)