[OOTB-infra] connecting to internal server

[Heiko Robert]

>> Default should be to access a VM thru VPN and to expose http thru 
>> reverse proxy. I don't see a need to expose every VM to the public or 
>> to expose many VMs to the internet. If you need a playground with 
>> lower security we may setup a different subnet for that but this 
>> doesn't answer how to make this secure and monitor against attacs 
>> from outside. If you need to reset VMs I wouldn't create VMs at all. 
>> Just return to a saved snapshot with a single command and you're 
>> done. So why not setting up the 2,3,4 or whatever VMs you need and 
>> keep them?
> I don't want to expose every VM to the public I am just trying to get 
> things done.
+1
getting things done should be our topmost priority
>
>>> Alternatively how would you feel about connecting one of the boxes 
>>> inside the bee infra into my own vpn? It probably wouldn't solve all 
>>> my issues but I would have an easier route for a lot of things.
>> I normally use a similar aproach using ipsec but this may also be 
>> configured/used with OpenVPN server peer config (which the intit.d 
>> scripts are meant to be used for). This allows to define clear 
>> firewall rules what can be seen in which direction for that client. 
>> But I only set this up with machines which are locked in a server 
>> room to allow automatic connection. So I would recommend to use the 
>> previous variant, but Ole may decide.
> Ole's boss may decide I guess you mean. I suppose that he or she would 
> be happy with us using the system in a responsible way. Whether that 
> requires being "locked in a server room" is another question. 
> Personally I think not, you should imagine that any person involved is 
> responsible enough to report a loss of equipment as a key breach.
3-4 people may do (and my experience is larger teams do not work that 
way as expected) but we should be able to involve the distro team also 
and many other volounteers willing to test, create build and testing 
environment for the main tasks we should work on:
make alfresco better
>
>>>
>>>> There is no way to connect to the internal network from the esx 
>>>> embedded system itself because there is no internal interface by 
>>>> design. That's a feature, not a restriction ;-)
>>> You may have to explain that one to me.
>> You mean the feature? This means VMs run normally in the dmz but the 
>> management interface is normally bound to a separate network card 
>> which is bound to the intranet. In this case there is no chance to 
>> access the management port from the dmz/from a VM even if there are 
>> bugs or leaks.
>
> Is this the behaviour by default or something you have chosen to 
> implement?
This is default. You have to choose the management interface on install 
and can add additional virtual switches later which are bound to other 
physical interfaces or Vlans to allow plug in VM's network interfaces.
I tried to configure a backdoor network by defining a virtual switch 
which connects the management network and the pfsense but got stucked 
with the default route of the esx kernel network.
>>>
>>>>
>>>> A new VM should be configured to use dhcp and you could forward 
>>>> ports to the internal IP from the gw1 address in case you really 
>>>> need to access a port from the internet.
>>>
>>> OK so your base VM has dhcp set, when I create a new VM I am going 
>>> to have to go to pfsense and look at the dhcp leases to find out 
>>> what the new address is, a bit awkward but I guess manageable.
>> hey man, what is your suggestion? This is just the easy to manage 
>> version in long term. You could always set static ips but this will 
>> get troubel since people are not good in keeping track on the IP docu.
>
> I am just stating for the record, that is to help Lanre's 
> documentation, what needs to be done to get a VM up in this scenario. 
> You may have responded, "no Martin you can do 'vm-info what-is-the-ip 
> <vm id>'" which could have been helpful but since you didn't I presume 
> there is no such command. Since you ask, what I would really like is 
> an interface which lets me set the IP address as well as disk and 
> memory etc. No worries I'm sure we'll get there.
If you're on the esx you only see, manage and configure the virtual 
hardware. From there you can only see or set the virtual mac address. 
There may be a way to get the IP address if the vm-tools are installed 
which serves the management api. That's the way how the vSphere client 
get's the ip addresses of a client on the info tab

To keep a discussion for the record I hate email lists because you have 
all these replys on replys and don't find the information you're looking 
for. I'd prefer to communicate in a ticket or forum style where only the 
pure answer to a question should be kept in a journal not the whole 
thread again and again. The existing redmine would be an option for that 
(it supports inbound and outbound mails, security/roles, private 
messages, routing) but I'm fine with any other solution but a public 
available email list. I know you're sceptic about redmine but if you've 
worked once with an integrated concept of wiki, tickets, forums, 
versioning repository with one search and security model and email 
handling mechanism you don't want to go back again... I'm not the 
promoter for redmine but for that concept which is awailable for free 
and without limitations like the most cloud services.

As a starting point we should

  * limit the copy text of answers to the minimum
  * try to focus on only one task/question/subject per mail

What's the opinion of the team?
>
>>>
>>>> If you want to predefine IPs you can configure this in the guest VM 
>>>> (we need to document and define static ip ranges) or better you add 
>>>> MAC address to fixed IPs using the pfsense user interface: 
>>>> https://pfsense.ecm4u.intra/status_dhcp_leases.php --> just click 
>>>> on the (+) sign and define IP and name.
>>>
>>> I don't mind configuring networking from inside the guest but I need 
>>> to connect to it first :-P
>> This is beeing done from the vShere Client on the console, but I 
>> would vote for the dhcp version since this will always be documented 
>> and consistent.
>>>
>>> I guess I need to connect to it to find out its mac address too.
>> you don't need to know the mac address. When you set up servername in 
>> the console everything should be done. As long there are free 
>> addresses in the dhcp pool your vm will get the same address (if not 
>> statcally mapped)
>
> "better you add MAC address to fixed IPs using the pfsense user 
> interface" - this is the only reason I thought I might need the mac 
> address
the key maybe a unique hostname and to use dhcp. You can pin a dedicated 
IP to a dhcp client. The most convenient way is to do that from the 
dhcp-leases list in pfsense.
dedicated IPs are only required for port forwards, right?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.xtreamlab.net/pipermail/ootb-infra/attachments/20150219/f305d21e/attachment-0001.html>