Apps security zones, routing to the correct (V)LAN Possible !?

Apps and Virtualization
1

My network is divided in multiple zones. Each zone having its VLAN.

  • Data and DB in the GreenZone
  • Internet facing in the RedZone
  • etc

My TrueNas system is connected to multiple zones via a trunk carrying multiple VLAN’s.

If an application VM, app or the TrueNas core itself, is connected / related to a certain security zone, responses towards the application arriving via a certain vlan >>should<< be answered via the same vlan.

And there it goes terribly wrong.

  • the TrueNAS core can not handle that
  • and I think apps can not handle that as well
  • luckily VM’s do route traffic the way it should !!

The problem is that truenas does route every thing back via the same routing table / the default gateway … (not ok at all IMHO)

I sincerely hope that I am wrong at least in relation to apps.

Lets give an example:

  • the TrueNAS core / base system is using VLAN-A and address range 192.168.A.<1-255>
  • I tie an app to security zone ‘X’ using VLAN-X having range 192.168.X.<1-155>
    (assign the app to e.g. 192.168.X.2)
  • a query arrives via VLAN-X towards ‘the app’
  • the app is responding and the answer is send via the TrueNas default gateway 192.168.A.1 where it should have be send to 192.168.X.1 !!
  • the gui of the App is also responding via 192.168.A.1

This is absolutely not ok! It is bocked in my network! It is assymetric routing and insecure.

So again I sincerely hope I am wrong, but this issue alone is enough reason for me not to use apps.

2

Apps can be bound to an IP address for ingress but will always use the single host routing table and network stack for egress.

That’s the state of affairs.

Use VMs if you must have isolation.

In TN CORE both jails and VMs could use isolated VLANs for all their networking, but unfortunately iX decided to end support for CORE.

3 Likes
3

What happens if you create two VLAN interfaces on TN, one for each zone, and bound each app to the corresponding IP.
Is the reply still via default gateway?

4

As I already wrote: yes.

The different IP addresses are used for ingress only. Use a VM if you need network isolation.

5

Or jail maker what seems still to work (or lxc)

6

If you have the vlan defined as an interface in TN, the routing/gateway should not be used.

7

Actual routing is so wrong, I really hope it will be fixed :yum:

For now apps are definitively a no go!

8

Routing is exactly how any Unix system with a single IP stack would do it. Or Cisco IOS - or whatever. The expectation that reply packets leave through the interface at which the requests arrive is just plain wrong.

Unless you explicitly implement policy routing.

I have my entire TN CE in a separate VLAN and only run apps on it.

9

Yep that is a solution, using a separate machine for each vlan / security zone.

What does not take away that it is ridiculous to have multiple physical machines for that! Perhaps not a problem for a company having many servers, but for private or small environments …

I really need a proper solution, I just do not accept this historical insecure mistake.
(which should have been fixed long ago!)

I am sometimes thinking in the direction of XCP-ng perhaps even running a couple of true-nas images.

For the moment apps = nogo only VM’s

10

Proxmox is nice I hear :wink:

Actually I run TrueNAS CE virtualised under Proxmox. But essential services are on TN CORE with jails and full isolation.

11

This is not a specific TN issue!

I have been able to do everything I wanted in TN.

Most people dont know how Apps (Docker) networking really work and that includes you from your understanding.

Once again:
Docker uses NAT networking so UNLESS you do create/define a macvlan or ipvlan for the Docker container, and a shim-interface in TN, there WON’T be communication between the Docker host and the Docker app!!!

Bottom line:
It works if you are willing to learn and test.

I challenge you to go to another Docker solution and get your setup to work the same way you tried in TN.

12

For me it is simple. A machine independent of how it is implemented is placed in a security zone and related vlan.

Every thing which violates this id, is ^not ok^ IMHO.