MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » July 2014

Re: How does networking (communication) work when in the cloud



fixed

blahblah is a firewall NAT translate.



On Thu, Jul 31, 2014 at 3:01 PM, Charles Wilt <charles.wilt@xxxxxxxxx>
wrote:

blahblah.dilgardfoods.com.

doesn't point to your LAN....it points to a particular server whose current
IP
1) is publically accessible, possibly on a private DMZ network behind a NAT
firewall..
2) is located in your building, but if on a DMZ network it is not
technically on your LAN.

#1 is all that matters, as long as that remains true, your sales people can
access the server without going through your office.

If blahblah.dilgardfoods.com. isn't on a DMZ network and is actually on
your LAN, that would mean either
A) your entire LAN is publically accessible
B) you have a hole in your firewall set up to NAT translate between the
public internet IP and the private IP of that server.

Whatever data center you chose would have a problem with A. They probably
won't approve of B either.

They should be able to set the blahblah server up on a DMZ.

However, they may balk at allowing blahblah in the DMZ to push/pull to the
IBMi on the internal network over FTP. As that would still require a hole
in the firewall (B)

Having the IBMi internal network pull/push to blahblah in the DMZ should
be doable.

Charles



On Thu, Jul 31, 2014 at 1:44 PM, Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx>
wrote:

By definition, a LAN is "local"...so asking for your LAN to be in a
remote
data center is a bit naive. :)

Well, duh. :)

I was trying to explain what I was after from a "practical" point of
view.



On Thu, Jul 31, 2014 at 1:14 PM, Charles Wilt <charles.wilt@xxxxxxxxx>
wrote:

By definition, a LAN is "local"...so asking for your LAN to be in a
remote
data center is a bit naive. :)

​To reword my original answer...

No the traffic doesn't have to come through your office as long as the
data
center is willing to allow it not to; at a price you're willing to pay.

You'd need to tell the data center you want the Windows server on a DMZ
segment of their network.

Charles



On Thu, Jul 31, 2014 at 12:42 PM, Jeff Crosby <
jlcrosby@xxxxxxxxxxxxxxxx

wrote:

The salespeople currently don't need to start a VPN to get to
blahblah.dilgardfoods.com.

I guess the crux of my question is does any and all access to the
servers
in the data center need to come through our office router to get
there?

What made me think about this was anticipating a power outage at our
office. It would be great in that the salespeople could continue to
send
orders and receive results as if there were no outage, because the
servers
in the data center would still be humming along. Workstations in our
office, however, would have a problem. :) If the outage was
extended,
we
could physically move our office printers and whatever workstations
we
want
to some other location with internet access. *That* location would
need
VPN access to the data center. The problem is what if
blahblah.dilgardfoods.com is pointing to an IP address at our office
instead of the data center?

I guess what I think I want is that my company's LAN is actually in
the
data center, not here. But it could be accessed from anywhere by
using a
PTP VPN.

Am I making sense or am I being naive?



On Thu, Jul 31, 2014 at 9:47 AM, Charles Wilt <
charles.wilt@xxxxxxxxx>
wrote:

It depends :)

I'd certainly push for having the Windows Servers in the same data
center
as the IBM i.

If not, I'd want a direct VPN between them. Can that be done?
Sure.
Will
both data centers be willing to do it and how much will it cost are
the
questions.

Same thing goes for the sales people's laptops. You say that
currently
"The
order gets sent from the laptop over the internet
to a Windows server in our office
​" Which to me means that the Windows server is in your DMZ and is
publically accessible ​with the right credentials. A data center
should
be
able to provide the same DMZ; though in my
experience
​ having a DMZ server at data center​ costs more than having
just private servers.

Now if your salespeople currently have to connect via VPN to your
office
before they can send the order to your windows server; then your
windows
server is private. There's no technical reason why the sales
people
couldn't VPN direct to the data center without needing to go
through
your
office. Again it's a question of what the data center is willing
to
do
and
for how much.

The data center might not be willing to allow the direct VPN given
the
added complexity. Remember, unlike a VPN to your office where the
remote
device usually has full access to the network in your build. A VPN
direct
to the data center has to be carefully set up so that the remote
devices
can only see your servers.

Charles


On Wed, Jul 30, 2014 at 3:21 PM, Jeff Crosby <
jlcrosby@xxxxxxxxxxxxxxxx>
wrote:

All,

Bear with me as it will take a bit to explain what I'm asking.

We're considering putting all our servers (IBM i and Windows) in
the
cloud
in a data center(s). Ideally (and our definite preference) the
IBM i
and
Windows would be in the same data center, but it's conceivable
they
would
be split into different data centers because the same provider
may
not
be
able to do both.

Here's the example. Our billing and invoicing is done on the IBM
i.
We
use a 3rd party ordering app for our outside salesreps to take
and
place
orders on laptops. The order gets sent from the laptop over the
internet
to a Windows server in our office, which FTPs it to the IBM i,
the
IBM
i
processes the order and FTPs the results back to the Windows
server.
The
Windows server then passes this on to the laptop. This happens
in
seconds.
So the flow looks like this:

Laptop --> Dilgard router --> Windows server --> IBM i -->
Windows
server
-->Dilgard router --> laptop

It goes from the laptop to our office and back. The laptops
connection
for
sending orders is DNS aware: blahblah.dilgardfoods.com. When
the
sales
rep clicks the option to send an order, the software connects,
sends
it,
and waits for the results.

When in a data center, there is a PTP VPN set up between our
office
and
the
data center. I assumed that once the servers are in a data
center,
when
a
salesrep sends an order the flow would be the same, except it
would
go
directly from the laptop to the data center and back. (This
assumes
we
changed blahblah.dilgardfoods.com to point to the data center
instead
of
our office.) There is no need at that point for it even to come
to
our
router in our office.

Something I was told however leads me to believe it does come
through
our
router, like this:

Laptop --> router at Dilgard --> router at data center --> data
center
Windows server --> data center IBM i --> data center Windows
server
-->
router at data center --> router at Dilgard --> laptop.

coming through our office twice, even though it doesn't "do
anything"
while
here. And if the Windows and IBM i servers are in different data
centers,
it's even worse:

Laptop --> router at Dilgard --> router at Windows data center
-->
data
center 1 Windows server --> router at Windows data center -->
router
at
Dilgard --> router at IBM i data center --> data center IBM i -->
router
at
IBM i data center --> router at Dilgard --> router at Windows
data
center
--> data center Windows server --> router at Windows data center
-->
router
at Dilgard --> laptop

It goes through our office *4* times, each time doing nothing but
being
routed back out. IOW there is no internet access provided at the
data
center (so to speak), the only access to the data center is via
the
PTP
VPN, which means everything has to come through our office.


Which way is it? Does it depend on the data center? If there is
an
online
document that explains how it works please point me to it. I
evidently
can't come up with the right search words. The older I get, the
dumber I
feel.

Thanks.


--
Jeff Crosby
VP Information Systems
UniPro FoodService/Dilgard
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531
www.dilgardfoods.com

The opinions expressed are my own and not necessarily the opinion
of
my
company. Unless I say so.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.




--
Jeff Crosby
VP Information Systems
UniPro FoodService/Dilgard
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531
www.dilgardfoods.com

The opinions expressed are my own and not necessarily the opinion of
my
company. Unless I say so.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.




--
Jeff Crosby
VP Information Systems
UniPro FoodService/Dilgard
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531
www.dilgardfoods.com

The opinions expressed are my own and not necessarily the opinion of my
company. Unless I say so.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.









Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact