<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
At he risk of being overly philosophical...<br>
<br>
There is an understandable tendency to assume that the networks behind
firewalls in organizations are completely discrete
space, separate from the Internet. It might be more useful to think of
such spaces as layers atop. Additionally, such layers can overlap.
The only rule is that there are no rules.<br>
<br>
Similarly, the term firewall is constraining because it tends to make
one think of traditional applications (packet filtering, NAT in typical
configurations) when in fact implementations of filtering and NAT can
be varied and nuanced.<br>
<br>
Matt, you hinted at this in your parenthetical "unless" clause below.<br>
<br>
Along the same lines, the term VPN is often used too loosely. In case
(2) below, you make an interesting point about there being no need for
a VPN. But something like it is needed ni the example you give.
Suppose we call it a "secure tunnel" instead?<br>
<br>
Matt wrote:
<blockquote
cite="midc11d02530706090507y2955ad66hf2aa46e00ea68c50@mail.gmail.com"
type="cite">Christopher,<br>
I understand exactly what you are saying.... but let's think about this
for a moment.<br>
<br>
If the networks we are stitching together have all public IPs, then
either one of two things is happening.<br>
<br>
1 - You can't access the IPs from the Internet, so they aren't really
public....they are from the public pool, and are depleting the limited
supply for IPs, but they aren't public, therefore they should be
private IPs.
<br>
<br>
2 - You can access the IPs from the Internet, therefore, there is no
need for a VPN.<br>
<br>
You should never never never NEVER use public IPs behind a firewall
(unless they can be accessed from the Internet). To put a public IP
behind a firewall where it can't be accessed is a waste of IP space,
and asking for routing problems.
<br>
<br>
<div><span class="gmail_quote">On 6/9/07, <b class="gmail_sendername">Christopher
LILJENSTOLPE</b> <<a href="mailto:cdl@asgaard.org">cdl@asgaard.org</a>>
wrote:</span>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Ahh
- I have to disagree here. A VPN makes a virtual connection<br>
between two networks. The state of those networks is entirely up to<br>
the people who run the networks. I know of a LOT of cases where<br>
people use VPNs to tunnel puddles of networks over the public
<br>
infrastructure to stitch a single AS together, for example.<br>
<br>
As far as 1918 vs. globally unique address space, there are many<br>
"public" and "private" networks that use the later. Anyone planning
<br>
on using 1918 space for VoIP infrastructure that is going to connect<br>
to external entities is not really thinking things through (or<br>
believe that SBC's will make everything painless). To quote Randy<br>
Bush...
<br>
<br>
Chris<br>
<br>
On Jun 8, 2007, at 23.30 , Matt wrote:<br>
<br>
> I'm not sure what the problem is. You use public IP, you use IPSEC,<br>
> static<br>
> route VZ IPs down the tunnel. No problem.<br>
>
<br>
> Right there is no problem, now. As everyone else in this thread<br>
> has said (for the most part). It works once you understand what<br>
> Verizon is trying to do, however prior to that their IPSEC layout
<br>
> is rather confusing. IE *normally* a VPN connects two PRIVATE<br>
> networks togethor... not two PUBLIC networks.<br>
> _______________________________________________<br>
> --Bandwidth and Colocation provided by <a
href="http://Easynews.com">Easynews.com</a> --<br>
><br>
> asterisk-biz mailing list<br>
> To UNSUBSCRIBE or update options visit:<br>
> <a href="http://lists.digium.com/mailman/listinfo/asterisk-biz">http://lists.digium.com/mailman/listinfo/asterisk-biz
</a><br>
<br>
_______________________________________________<br>
--Bandwidth and Colocation provided by <a href="http://Easynews.com">Easynews.com</a>
--<br>
<br>
asterisk-biz mailing list<br>
To UNSUBSCRIBE or update options visit:
<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-biz">http://lists.digium.com/mailman/listinfo/asterisk-biz</a><br>
</blockquote>
</div>
<br>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-biz mailing list
To UNSUBSCRIBE or update options visit:
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-biz">http://lists.digium.com/mailman/listinfo/asterisk-biz</a>
</pre>
</blockquote>
</body>
</html>