[OOTB-infra] connecting to internal server

Tue Feb 17 20:02:36 GMT 2015

Redirecting conversation back to the list again, please can we keep this 
as the default.

On 17/02/15 19:56, Heiko Robert wrote:
>
> Am 17.02.2015 um 17:28 schrieb Martin Cosgrave:
>> On 17/02/15 17:03, Heiko Robert wrote:
>>> Hi Martin,
>>>
>>> most virtualisation servers like VMWare handls/encapsulate the VMs 
>>> in a sandbox without any shared resource, network between the 
>>> management server and VMs (baremetal concept). The linux embedded 
>>> virtualisation frameworks like KVM, Vagrant are not so strict and 
>>> run inside a full blown OS and may not so focused on hosting 
>>> enterprise apps rather than getting easy virtualisation for linux 
>>> admins on any hardware. So you should keep this in mind when 
>>> accessing the ootb environment. You can get only network access to 
>>> the internal network using the interface of a VM. In our case it's 
>>> gw1 for direct access from the internet or the internal address via 
>>> VPN (which is routed thru gw1).
>>
>> OK so if one has access to the esx box via ssh, that's for 
>> controlling and inititating vms. But from there you can't get access 
>> to the network hosted by the VMWare host. So each time I make a new 
>> VM I have to also go into pfsense and set up port forwards etc.
> I think this shouldn't be the default. This is as if you try to to 
> expose any computer in a company network to the public internet. This 
> should be the exception.

I totally agree, I was speaking from a standpoint of my not being able 
to use the VPN.

I believe you have confirmed that the VPN connection no longer forces 
traffic through the bee network, so I am able to test that again, 
however I have not as yet.

> 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.

>>
>> You know what would be really great? If the ESXi box could join the 
>> pfsense VPN, then we could just join a VPN without any funky routing 
>> stuff going on and be able to see the ESX management ports from our 
>> local networks.
> I'll try this when I mentioned "tweaking" VPN routing

Great, it would be the best solution as far as I can see.

>>
>> 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.

>>
>>>
>>> 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?

>>
>>> Connecting to the esx IP is for managing host services only like 
>>> backup/recovery, copying or manipulating VM config resources 
>>> directly, calling services commands from a ssh shell.
>>>
>>> Again: try to forget the esx1 address and work with the gw1 address. 
>>> Only use gw1 for connecting from vShere Client or from VMWare 
>>> Converter or ovftool command line tool
>>
>> you say 'again', it's the first time I've heard that you have to 
>> connect to gw1 to use the client. Have you never heard of the 
>> principle of least surprise? Wouldn't it make sense in this case to 
>> connect to the 'esx1' host to use the esx ports? No wonder I was not 
>> able to connect with any tools I tried. >.<
> vmware tools trying to connect the esx management services need to 
> connect to the esx1 ip/ports and may require to work around firewall 
> rule in our setup
> ssh clients trying to connect to vms should allways use the gw1 ip
> 'again' is meant to the previous mail

apologies, you made a correction regarding the esx1/gw1 confusion

>>
>>>
>>> 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 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
>>
>>>
>>> Heiko
>>>
>>> P.S.: I cc'd lanre and Ole to share the knowledge
>>
>> I added the list, couldn't see anything sensitive within. Redacted a 
>> couple of port numbers.
> Unfortunately I just read this at this moment because I try to answer 
> your mails durch my job and I read mails from back
> Fortunately I use a different email address for our internal 
> communication (and don't want this email on the list). The list send 
> me a notification waiting for approval but I revoked.

Unfortunately it seemed to make it to the list, perhaps Lanre is 
approving them, when I looked it was not pending. I think the messages 
you sent made it to the main list.

Martin

>
> -- 
> Heiko Robert [heiko.robert at ecm4u.de]
> Consultant / Geschäftsführender Gesellschafter
>
> ecm4u GmbH
> http://www.ecm4u.de
> Hölderlinplatz 2b
> 70193 Stuttgart
>
> t: +49 (711) 912775-72
> m: +49 (176) 347475-72
> f: +49 (711) 912775-80
>
> ecm4u GmbH - die IT in Prozessen einfach sinnvoll nutzen
> Handelsregister: Amtsgericht Stuttgart HRB 734004, Geschäftsführung: Heiko Robert

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