I have an internal use case for this!

Hi Frank,

what Sven says is not QUITE true (or at least misleading) and your use case could work (though I'd probably also prefer VLANs if your infrastructure allow you to use them).

First we should talk about the RED provisioning protocol, later on we'll talk about the RED protocol itself and what it is capable of doing and how it interacts with the ASG:

RED Provisioning:

In order to configure a RED device, you MUST use the RED Provisioning Service (RPS). This Service is hosted in the cloud (at red.astaro.com) and is a central hub for every RED configuration.

First of all you'll have to register an ASG as a configuration provider with the RPS. This happens if you initially enable the RED functionality on your ASG. In order to succeed with the registration, the ASG itself has to be able to reach red.astaro.com on Port TCP 3400 during this phase. The ASG should also be able to reach the RPS everytime you create a new RED device in your ASG, as the configuration is written to the RPS if you do so.

The configuration itself consists of some key material and the IP address or DNS name that the RED device uses to establish the tunnel to the ASG.
A common misconception is that this DNS name or IP has to be public; it doesn't have to be. It's just a value for the RED configuration.

If the RED device is initially shipped or cannot contact the ASG and establish a tunnel, it tries to contact the RPS via TCP Port 3400 again at host red.astaro.com. It then sends its serial number (as an factory built in x509 certificate) to the RPS and downloads its configuration from there, stores the configuration locally, reboots and tries to establish the tunnel with the ASG.

The RPS service itself and the RED communication with it is mutually authenticated. There is no way to "mock" an internal RPS by just redirecting red.astaro.com to an internal IP, since the server would have to have to matching private SSL key to be able to provide a configuration to the RED devices as they have the server's certificate in their firmware.

So you have to use the pre staging strategy for private networks (at least at the moment).

Interaction ASG - RED:

If you register a RED device to your ASG two things happen: a) the configuration is stored on the internet based cloud service (RPS) but more importantly a virtual interface that terminates the RED tunnel is created. This interface is the OS's entry point for each ethernet packet that is transmitted via the RED tunnel. 

As this interface acts as any other physical or VLAN interface on the ASG, you can use it in this way. The quick network setup wizzard assigns an IP address to the RED interface and creates a DHCP server for it. This is however not necessary.

The tunnel RED - ASG is established based on the configuration information that was downloaded from the RPS. However if there is a valid configuration stored on the RED device, it does not have to contact the RPS before establishing the configuration. The ports used here are TCP and UDP 3400.

This allows you to pre-configure RED devices to work in a network environment where there is no internet connection at the branch offices (or in your case you don't have to allow the RED to contact the internet from the local area network). 

So, to get your scenario working:
a) enable RED on your ASG
b) create a RED device with your RED serial number: make sure that you use the LAN facing internal IP as the "ASG hostname" as this is the IP or DNS name to which the RED device will later on establish the tunnel.
c) you may use the quick network wizzard, the newly created network range will then be your special DMZ. In case you have a preexisting DMZ that you want to connect the RED to, you can also skip the quick network setup part and bridge the reds interface to this DMZ later on
d) you connect the RED to a link where it can directly access the RPS and fetch its configuration from there. 
e) rewire your RED once it has fetched its configuration to the place in your LAN where you want to establish the guest network and connect a guest switch or your guest clients directly to the RED device.

This allows you to fully separate them from the surrounding LAN even if you don't have VLAN technology at your edge switches. You can even enforce a kind of poor man's NAC using SSL VPN technology for this guest network only or by using static DHCP leases for your guests.

Hope that clarifies & helps
Christian

Hi Frank,

what Sven says is not QUITE true (or at least misleading) and your use case could work (though I'd probably also prefer VLANs if your infrastructure allow you to use them).

First we should talk about the RED provisioning protocol, later on we'll talk about the RED protocol itself and what it is capable of doing and how it interacts with the ASG:

RED Provisioning:

In order to configure a RED device, you MUST use the RED Provisioning Service (RPS). This Service is hosted in the cloud (at red.astaro.com) and is a central hub for every RED configuration.

First of all you'll have to register an ASG as a configuration provider with the RPS. This happens if you initially enable the RED functionality on your ASG. In order to succeed with the registration, the ASG itself has to be able to reach red.astaro.com on Port TCP 3400 during this phase. The ASG should also be able to reach the RPS everytime you create a new RED device in your ASG, as the configuration is written to the RPS if you do so.

The configuration itself consists of some key material and the IP address or DNS name that the RED device uses to establish the tunnel to the ASG.
A common misconception is that this DNS name or IP has to be public; it doesn't have to be. It's just a value for the RED configuration.

If the RED device is initially shipped or cannot contact the ASG and establish a tunnel, it tries to contact the RPS via TCP Port 3400 again at host red.astaro.com. It then sends its serial number (as an factory built in x509 certificate) to the RPS and downloads its configuration from there, stores the configuration locally, reboots and tries to establish the tunnel with the ASG.

The RPS service itself and the RED communication with it is mutually authenticated. There is no way to "mock" an internal RPS by just redirecting red.astaro.com to an internal IP, since the server would have to have to matching private SSL key to be able to provide a configuration to the RED devices as they have the server's certificate in their firmware.

So you have to use the pre staging strategy for private networks (at least at the moment).

Interaction ASG - RED:

If you register a RED device to your ASG two things happen: a) the configuration is stored on the internet based cloud service (RPS) but more importantly a virtual interface that terminates the RED tunnel is created. This interface is the OS's entry point for each ethernet packet that is transmitted via the RED tunnel. 

As this interface acts as any other physical or VLAN interface on the ASG, you can use it in this way. The quick network setup wizzard assigns an IP address to the RED interface and creates a DHCP server for it. This is however not necessary.

The tunnel RED - ASG is established based on the configuration information that was downloaded from the RPS. However if there is a valid configuration stored on the RED device, it does not have to contact the RPS before establishing the configuration. The ports used here are TCP and UDP 3400.

This allows you to pre-configure RED devices to work in a network environment where there is no internet connection at the branch offices (or in your case you don't have to allow the RED to contact the internet from the local area network). 

So, to get your scenario working:
a) enable RED on your ASG
b) create a RED device with your RED serial number: make sure that you use the LAN facing internal IP as the "ASG hostname" as this is the IP or DNS name to which the RED device will later on establish the tunnel.
c) you may use the quick network wizzard, the newly created network range will then be your special DMZ. In case you have a preexisting DMZ that you want to connect the RED to, you can also skip the quick network setup part and bridge the reds interface to this DMZ later on
d) you connect the RED to a link where it can directly access the RPS and fetch its configuration from there. 
e) rewire your RED once it has fetched its configuration to the place in your LAN where you want to establish the guest network and connect a guest switch or your guest clients directly to the RED device.

This allows you to fully separate them from the surrounding LAN even if you don't have VLAN technology at your edge switches. You can even enforce a kind of poor man's NAC using SSL VPN technology for this guest network only or by using static DHCP leases for your guests.

Hope that clarifies & helps
Christian