Combining IN and OUT appliances into one

[Dmitry@Rivermine]

Hi, is there any reason why I would not be able to combine the IN and OUT appliance into one "GW" appliance so that I can utilize only one IP address per application?

I'm currently trying to debug why the IN app does not come up with an "in" interface configured but if anyone has seen the answer please let me know where I can find it.

[PeterNic]

Dmitry,

(I thought I had answered this... maybe I didn't publish it... sorry for the delay)

There is no reason you could not combine the IN and OUT appliance, or the IN and NET appliance. You will need to read through the iptables setup in the two appliances you are combining and produce a combined set. The iptables are configured by script(s) residing in the /appliance directory in each appliance.

Let me know if this is still not working for you.


Regards,
-- Peter

[Dmitry@Rivermine]

As the matter of fact I have done this with some "pain" but as a result I've fully understood and learned how iptables works :) Since I'm not a grid controller I've "lost" couple of the "in/net" appliances in the process.

[JeremySuo]

I would be interested in seeing what you have built. Any chance you can send a copy to TGL for me to look at on my dev grids? Any thought to adding SNMPD support so you can then graph bandwidth usage.

Thanks,

Jeremy

[Vlad]

While there are no technical problems in doing this, there are other reasons not to build custom "boundary" appliances like In and Out. For example, the upcoming 2.1 version of AppLogic will allocate IP addresses authomatically. Your custom In/OUT variations may or may not work with this...

As a general rule, we (3Tera) try to stay out of your way on the "inside" of your application and/or appliances, and interact with your code on well-defined boundaries. One consequence of this rule is that you are much less likely to experience compatibility issues on inside than on the boundaries.

Another example: in this version of AppLogic, you can still use one terminal for two different protocols; for example, you may be able to SSH to a database server through its IN terminal. Bad idea - we will be closing this loophole very soon :-)

Vlad

[Dmitry@Rivermine]

Vlad, please explain more about your previous statement.
The reason why I setup an IN/OUT appliance because I cannot afford to use 2 IP addresses per my application.

What do you mean by "the upcoming 2.1 version of AppLogic will allocate IP addresses authomatically". What kind of IP addresses? As I'm aware right now the "internal" ip addresses for the gateways are in fact setup automatically. However, the public ips are configured in the IN appliance through application assembly by the admin. Are you saying that the IN appliances will automatically take up a public IP address from the range assigned to the grid?

And last you said you are closing a loophole that might allow ssh to a database server through its IN terminal. Isn't idea of port forwarding exactly what this is all about? How are you planning to close this loophole? I would like to be able to have an ssh access to my database without having to go through controller. In our setup we usually install Cisco firewall before the grid that sets up site to site VPNs that allows the ssh go through. This ssh tunnel is then port forwarded to a database.

[Vlad]

Vlad, please explain more about your previous statement.
The reason why I setup an IN/OUT appliance because I cannot afford to use 2 IP addresses per my application.


What do you mean when you say you "can't afford" to use 2 IP addresses per app? Additional IP addresses are available from LT...


What do you mean by "the upcoming 2.1 version of AppLogic will allocate IP addresses automatically". What kind of IP addresses? As I'm aware right now the "internal" ip addresses for the gateways are in fact setup automatically. However, the public ips are configured in the IN appliance through application assembly by the admin. Are you saying that the IN appliances will automatically take up a public IP address from the range assigned to the grid?


Yes, we are adding a mechanism for allocating public IP addresses automatically. The idea is to have humans deal with DNS names only, and let the system deal with IP addresses, registering DNS names, etc.


And last you said you are closing a loophole that might allow ssh to a database server through its IN terminal. Isn't idea of port forwarding exactly what this is all about? How are you planning to close this loophole? I would like to be able to have an ssh access to my database without having to go through controller. In our setup we usually install Cisco firewall before the grid that sets up site to site VPNs that allows the ssh go through. This ssh tunnel is then port forwarded to a database.
[/quote]

Perhaps I misspoke. You are free to SSH into your database server (or any other appliance), as long as you are doing it through a terminal that is configured to accept SSH. In the example you are giving, I would create a new input on the database appliance, call it "CTL" or "CLI", limit it to SSH only, and then wire it to wherever you want the SSH control to come from.

What I call a loophole is the use of a single input terminal for two or more unrelated protocols. This is an obvious security risk, and it is also a poor design practice.

[Dmitry@Rivermine]

Our initial setup was done such that we had limited range of IPs to use. Although we have increased the range I still consider it wasted resource if more than on IP is used for App.

I would disagree with the notion of using a single IN terminal for single protocol. I consider IN/OUT appliance to be a software firewall that's setup in front of the network. Being such, it makes sense to me to allow multiple forwarding rules as well as multiple accept rules for different service types much like a physical firewall would do.

[PeterNic]

Clarification: Vlad referred to terminals that appliances use to talk among themselves (input or output terminals); each terminal on an appliance is supposed to have single role -- so for example, you can connect the fs output of your web server to one appliance and your log output to another, or both the fs and log terminals to the same appliance.

On the other hand, the IN and OUT gateway appliances are boundaries of the app; of course you can have multiple protocols per such gateway. Our prototype catalog even has a port switch appliance (PS8) that allows you to separate multiple incoming protocols and feed them to different appliances.

Regards,
-- Peter

[Vlad]

Peter, thanks for clarifying this for me - Dmitry, my bad - I confused the issue by speaking about terminals and gateways in the same message.

As far as IP addresses are concerned, they are $.50 per month per IP address, or $6 per year per IP address. On the other side, typical fully loaded costs in the US are $75 per hour when all company expenses are included.

So, investing engineering time to reduce the number of IP addresses only pays off if you can eliminate 12 or more IP addresses per hour of time spent. Software companies typically expect to make a 65% gross margin for every dollar they spend, so this means to turn an equivalent profit, you need to eliminate no less than 34 IP addresses per hour :-)

Vlad