diff --git a/content/u/blog/how-to-build-an-openstack-alternative-step-2-secure-the-network/contents.lr b/content/u/blog/how-to-build-an-openstack-alternative-step-2-secure-the-network/contents.lr
index b79c832..54d2631 100644
--- a/content/u/blog/how-to-build-an-openstack-alternative-step-2-secure-the-network/contents.lr
+++ b/content/u/blog/how-to-build-an-openstack-alternative-step-2-secure-the-network/contents.lr
@@ -8,7 +8,7 @@ twitter_handle: ungleich
 ---
 _hidden: no
 ---
-_discoverable: no
+_discoverable: yes!
 ---
 abstract:
 Let's secure the VM network
@@ -19,7 +19,7 @@ In the second step of building an OpenStack alternative we have a look
 on how to secure the network.
 
 In the first step we described [how to setup a
-protoype](how-to-build-an-openstack-alternative-step-1).
+protoype](../how-to-build-an-openstack-alternative-step-1).
 
 Note: the name of our OpenStack alternative is
 **uncloud**.
@@ -28,12 +28,12 @@ Note: the name of our OpenStack alternative is
 
 Users should be able to do what they want and not limited in their
 actions. On the other hand, users should be unable to disturb other
-users.
+users. It's very much like in real life.
 
 ## General policy: no firewall
 
-So for most of the user created traffic there should not be a firewall
-rule on the virtualisation stack. Users should be free to configure
+So for most of the user generated traffic there should be no firewall
+rules in uncloud. Users should be free to configure
 their own policies on the VM.
 
 ## Network types
@@ -92,21 +92,64 @@ IP address of another machine. We can achieve this by adding a chain
 specific for each VM network interface:
 
 ```
-    chain vm1 {
-        ether saddr != 02:00:f0:a9:c4:4e drop
-        ip6   saddr != 2a0a:e5c1:111:888:0:f0ff:fea9:c44e drop
-    }
+iifname tap1 ether saddr 02:00:f0:a9:c4:4e ip6 saddr 2a0a:e5c1:111:888:0:f0ff:fea9:c44e accept
 ```
 
-This way any incorrect mac address and any incorrect IPv6 source
-address will be blocked. If a customer requested a network for the VM
-(/64 or /48 for instance), it can easily be prepended to the vm1 specific
-chain:
+With this we can even allow routing a network to a VM and allowing
+it to use any IPv6 address in that network:
 
 ```
-    chain vm1 {
-        ip6   saddr 2a0a:e5c1:111:cafe::/64 accept
-        ether saddr != 02:00:f0:a9:c4:4e drop
-        ip6   saddr != 2a0a:e5c1:111:888:0:f0ff:fea9:c44e drop
-    }
+iifname v343a-0 ether saddr 02:00:f0:a9:c4:4f ip6 saddr 2a0a:e5c1:111:888:0:f0ff:fea9:c44f accept
+iifname v343a-0 ether saddr 02:00:f0:a9:c4:4f ip6 saddr 2a0a:e5c1:111:1234::/64 accept
 ```
+
+## Putting it all together
+
+The following code is a full nftable ruleset
+for securing the VM network traffic.
+Note that it uses the prerouting hook so
+that we can use the **ibrname** statement.
+This is necessary because we don't want to
+filter after routing or in a forwarding mode, but we want to already filter it
+**prerouting** (hence the name).
+
+```
+flush ruleset
+
+table bridge filter {
+    chain prerouting {
+        type filter hook prerouting priority 0;
+        policy accept;
+
+        ibrname br100 jump br100
+    }
+
+    chain br100 {
+        # Allow all incoming traffic from outside
+        iifname vxlan100 accept
+
+        # Default blocks: router advertisements, dhcpv6, dhcpv4
+        icmpv6 type nd-router-advert drop
+        ip6 version 6 udp sport 547 drop
+        ip  version 4 udp sport 67 drop
+
+        jump br100_vmlist
+        drop
+    }
+    chain br100_vmlist {
+        # VM1
+        iifname tap1 ether saddr 02:00:f0:a9:c4:4e ip6 saddr 2a0a:e5c1:111:888:0:f0ff:fea9:c44e accept
+
+        # VM2
+        iifname v343a-0 ether saddr 02:00:f0:a9:c4:4f ip6 saddr 2a0a:e5c1:111:888:0:f0ff:fea9:c44f accept
+        iifname v343a-0 ether saddr 02:00:f0:a9:c4:4f ip6 saddr 2a0a:e5c1:111:1234::/64 accept
+    }
+}
+```
+
+## Status
+
+With this second step we create the basis for actually running VMs
+that we (as an operator) don't trust. So now we have a prototype and
+we have network security. We probably want to begin to automate things
+in the next step.
diff --git a/content/u/blog/uncloud-next b/content/u/blog/uncloud-next
index 8cbd582..68b7819 100644
--- a/content/u/blog/uncloud-next
+++ b/content/u/blog/uncloud-next
@@ -4,3 +4,62 @@
 - trigger / postgres / etcd
 - metadata!
 - building vm images!
+- generate tap names matching vm??? problem, because inteerfaces are
+  limited in length!
+
+[root@diamond hackcloud]# ip link add b23456789012345 type bridge
+[root@diamond hackcloud]# ip link add b234567890123456 type bridge
+Error: argument "b234567890123456" is wrong: "dev" not a valid ifname
+[root@diamond hackcloud]#
+
+- VMID is not uuid, but counter; using hexa; using 16**10,
+gives 1099511627776 VMs
+
+>>> (16**10)/(1000*24*365)
+125515.02600182648
+
+interface names:
+
+x = vxlan ?
+b = bridge
+v = vm
+
+
+=> 16 types possible
+
+10+1 used => 4 left
+
+2 positions for interface id? => 256 interfaces per VM
+
+mac:
+
+48 bits = 6 bytes
+1 byte = 2hexa positions
+
+prefix is 02:00: = 2 bytes
+we have 4 bytes = 8 hexa left!!!!
+embed mac suffix as ID!
+full mac = 12 bytes
+
+No vmprefix + counter -> because counter size might always be wrong
+(how many interfaces? 16? 256? ... )
+
+--------------------------------------------------------------------------------
+No stale firewall entries as we regnerate, not keep the list!
+
+table bridge filter {
+    chain prerouting {
+        type filter hook prerouting priority 0;
+        policy accept;
+
+        ibrname br100 jump netpublic-$version
+    }
+    chain netpublic-10 {
+    ...
+    }
+
+}
+
+can generate new full chain, change only the jump
+
+--------------------------------------------------------------------------------