VPN question

Hi,

I have a question about VPNs into a private network with different
security zones. All remote access clients have to access the part of the
private network where they are normally ocated. So some of the remote
clients shall access one zone, while others shall access other zones. My
question is: does ISA server support a scenario where one server
(probably the ISA-server) is located in the perimeter network and
receives all encapsulated requests from the remote clients. The VPN
traffic is unwrapped and inspected at the server before it is
encapsulated again with the destination address (found in the inner
packet) in the zone where the remote clients normally are located (when
at work). All zones will have a Remote Access Server to decrypt and
unwrap traffic from the server in the perimeter network. I do not know
if this will work, especially when it comes to the addressing issues,
and the encapsulation of packets at the server in the perimeter network.
I hope someone understands the problem, it is a little bit complex to
describe in text...

Any advice, suggestions or recommendations would be greatly appreciated!


Thanks,
Lill

I use the *'s only for emphasis,...so I'm not yelling

"lill" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> (probably the ISA-server) is located in the perimeter network and
> receives all encapsulated requests from the remote clients. The VPN
> traffic is unwrapped and inspected at the server

ISA doesn't "do" VPN. It is RRAS that actually does the VPN although RRAS
is (and should be) configured from within the ISA interface. ISA does not
process nor in any way inspect the contents within the VPN Tunnel (it
doesn't even see the Tunnel). In fact there is no way it can,...it just
isn't possible.

> before it is
> encapsulated again with the destination address

There is no "encapsulated again",...it doesn't happen twice. The VPN
encapsulation/de-encapsulation occurs *only* the the ends (termination
point) of the Tunnel. If the Clients are on the outside, such as your
Remote Clients, then the Tunnel terminates at the ISA box as it goes into
and exits RRAS. Once de-capsulated it is simply nothing more than normal
*internal* traffic and the VPN no longer exists at that point. This traffic
is handled identically as with all other *internal* traffic. The Client is
considered internal because they receive an internal IP# bound to their
logical VPN Adapter when the VPN Connection is established. What ever IP#
is assigned to their local LAN adapter (or Dialup Adapter if a modem) is
totally irrelevant and means nothing. The IP# of the external NIC of the
ISA is also totally irrelevant to the traffic inside the Tunnel.

You simply manage the clients in exactly the same way you would manage
clients that are physically within the private network,...that is the whole
point of what VPN is all about.


--

Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

I understand what you are saying. My question was simply to find out if
RRAS was capable of encapsulating a de-capsulated packet and forward it
using the information in the inner packet. The reason for doing so is
that I want the packet to be tunneled yet again inside the private
network, after inspected by the server (which are the reason for
deploying ISA server in this case - the firewall feature is needed to
inspect the packets after de-capsulated (of course)). If the ISA server
running RRAS is not located in the same subnet that the remote clients
needs access to, it might be a good idea to have VPN tunnels inside the
private network also.

This is what I want:
1. ISA server running RRAS receives encapsualted traffic from remote
client
2. The traffic is de-capsulated, and the destination address in the
inner packet belongs to a different subnet
3. The ISA server running RRAS "finds out" where to forward the traffic
(using a table or something). The new destination is located at the same
subnet as another server running RRAS.
4. The traffic is encapsulated for the second time and sent through the
new tunnel to the RRAS in the correct subnet.
This way the firewalls in the private network do not have to "open" for
all kind of traffic from the remote clients.

I do understand that the clients are to be handled the same way as if
they where located in the private network. This is why they have to get
the same IP address as they would if they wher physically connected to
the subnet.

This may be impossible, but from a security point of view it makes
sense.




Thanks,
Lill



"Phillip Windell" <@.> wrote in message
news:%23VbF$(E-Mail Removed)...
> I use the *'s only for emphasis,...so I'm not yelling
>
> "lill" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > (probably the ISA-server) is located in the perimeter network and
> > receives all encapsulated requests from the remote clients. The VPN
> > traffic is unwrapped and inspected at the server
>
> ISA doesn't "do" VPN. It is RRAS that actually does the VPN although
RRAS
> is (and should be) configured from within the ISA interface. ISA does
not
> process nor in any way inspect the contents within the VPN Tunnel (it
> doesn't even see the Tunnel). In fact there is no way it can,...it
just
> isn't possible.
>
> > before it is
> > encapsulated again with the destination address
>
> There is no "encapsulated again",...it doesn't happen twice. The VPN
> encapsulation/de-encapsulation occurs *only* the the ends (termination
> point) of the Tunnel. If the Clients are on the outside, such as your
> Remote Clients, then the Tunnel terminates at the ISA box as it goes
into
> and exits RRAS. Once de-capsulated it is simply nothing more than
normal
> *internal* traffic and the VPN no longer exists at that point. This
traffic
> is handled identically as with all other *internal* traffic. The
Client is
> considered internal because they receive an internal IP# bound to
their
> logical VPN Adapter when the VPN Connection is established. What ever
IP#
> is assigned to their local LAN adapter (or Dialup Adapter if a modem)
is
> totally irrelevant and means nothing. The IP# of the external NIC of
the
> ISA is also totally irrelevant to the traffic inside the Tunnel.
>
> You simply manage the clients in exactly the same way you would manage
> clients that are physically within the private network,...that is the
whole
> point of what VPN is all about.
>
>
> --
>
> Phillip Windell [MCP, MVP, CCNA]
> www.wandtv.com
>
>
>

"lill" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> that I want the packet to be tunneled yet again inside the private
> network,

Sorry, no, that is just silly.

> This way the firewalls in the private network do not have to "open" for
> all kind of traffic from the remote clients.

??? You totally lost me with that one. The firewalls have nothing to do
with it. VPN has one purpose and one purpose only,...to get you from point
"A" to point "B" privately across the Internet, once that happens it's over.
It is up to other means of management to handle it from there. I don't know
what you mean by "firewalls in the private network" and how that has
anything to do with "remote clients". You'll have to explain your topology
design a lot more clearly.

--

Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

Just to add to what Philip said, you really need to separate remote access
and local traffic issues. If you want additional security on your LAN, look
as something like IPSec.

"Phillip Windell" <@.> wrote in message
news:#45CDO#(E-Mail Removed)...
>
> "lill" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > that I want the packet to be tunneled yet again inside the private
> > network,
>
> Sorry, no, that is just silly.
>
> > This way the firewalls in the private network do not have to "open" for
> > all kind of traffic from the remote clients.
>
> ??? You totally lost me with that one. The firewalls have nothing to do
> with it. VPN has one purpose and one purpose only,...to get you from
point
> "A" to point "B" privately across the Internet, once that happens it's
over.
> It is up to other means of management to handle it from there. I don't
know
> what you mean by "firewalls in the private network" and how that has
> anything to do with "remote clients". You'll have to explain your
topology
> design a lot more clearly.
>
> --
>
> Phillip Windell [MCP, MVP, CCNA]
> www.wandtv.com
>
>
>

Thank you for your opinion.
But it is a fact that it might be interesting to use tunnels inside an
internal network too. In my case I will like to have a Remote Access VPN
from the remote client to the server running RRAS/ISA in the perimeter
network. In addition to that, I want to have a server-to-server
(host-to-host) VPN tunnel from servers running RRAS inside the internal
network and the RRAS/ISA server in the perimeter network. The traffic
from the remote clients are inspected by the RRAS/ISA server before it
is forwarded to the security zone (subnet), through a new tunnel, to get
access to the resources.

Firewalls is very much an issue in a VPN scenario since traffic from the
remote client sghould be inspected after de-capsulation and decryption.
I do know that security in the LAN is one thing, and Remote Access VPNs
another. But I do need both in my case, so what I am trying to define is
a scenario where both security issues are defined. I also notice that
what I called "private network" in the earlier mails really should be
"internal" network or "local" network.



-Lill


"Bill Grant" <not.available@online> wrote in message
news:%(E-Mail Removed)...
> Just to add to what Philip said, you really need to separate remote
access
> and local traffic issues. If you want additional security on your LAN,
look
> as something like IPSec.
>
> "Phillip Windell" <@.> wrote in message
> news:#45CDO#(E-Mail Removed)...
> >
> > "lill" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> > > that I want the packet to be tunneled yet again inside the private
> > > network,
> >
> > Sorry, no, that is just silly.
> >
> > > This way the firewalls in the private network do not have to
"open" for
> > > all kind of traffic from the remote clients.
> >
> > ??? You totally lost me with that one. The firewalls have nothing
to do
> > with it. VPN has one purpose and one purpose only,...to get you
from
> point
> > "A" to point "B" privately across the Internet, once that happens
it's
> over.
> > It is up to other means of management to handle it from there. I
don't
> know
> > what you mean by "firewalls in the private network" and how that has
> > anything to do with "remote clients". You'll have to explain your
> topology
> > design a lot more clearly.
> >
> > --
> >
> > Phillip Windell [MCP, MVP, CCNA]
> > www.wandtv.com
> >
> >
> >
>
>

"lill" <(E-Mail Removed)> wrote in message
news:#(E-Mail Removed)...
> But it is a fact that it might be interesting to use tunnels inside an
> internal network too.

I know, but as an illustration, it might be interesting to drive a
motorcycle up and down the hallway in your house, but that is not what it is
design for. There are so many ways out there to do this "right" why do you
want to spend so much time, effort, and creativity, to do it "wrong"?

> In my case I will like to have a Remote Access VPN
> from the remote client to the server running RRAS/ISA in the perimeter
> network. In addition to that, I want to have a server-to-server
> (host-to-host) VPN tunnel from servers running RRAS inside the internal
> network and the RRAS/ISA server in the perimeter network. The traffic
> from the remote clients are inspected by the RRAS/ISA server before it
> is forwarded to the security zone (subnet), through a new tunnel, to get

Sounds like a Back-to-back DMZ. You can't do what you think there either.
You have to run one Tunnel inside the other Tunnel to even get across a B2B
DMZ to begin with and there is no way to "inspect" the contents within the
Tunnel.

Read about B2B DMZs and VPN by searching with "DMZ" and "VPN" on
www.isaserver.org

Your intent to do this with firewalls is just simply wrong. Firewalls run
NAT along with the rest of what they do,...you don't want NAT...this is not
suitable for what you want to do. You control the content of internal
traffic by using routers (not firewalls) and subnets,...that's half the
reason such things exist,...that is what they are for. now if you find a
firewall that you can disable NAT and have it work like a router then that
would be fine. ISA won't work for the same reason,...it does "proxying"
(similar but different than NAT) and you don't want anything "proxying" the
requests between subnets in the private system, it creates a "trusted" and
"untrusted" subnet and which ever subnet is the lucky one to be considered
"untrusted" gets cut off at the knees and no longer functions as a LAN.

> I do know that security in the LAN is one thing, and Remote Access VPNs
> another. But I do need both in my case, so what I am trying to define is
> a scenario where both security issues are defined. I also notice that

Use Routers with ACLs between the subnets. You have not stated exactly what
kind of "unwanted" traffic you are wanting to "inspect" .....you may be
going through all this hassle for something that is really a non-issue
anyway....like for example, use a firewall to stop a virus when that is not
what stops viruses, AV software does that.


--

Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

By tunneling traffic inside the internal network you do not have to open
the internal firewalls for all kinds of traffic, only for VPN traffic
(IKE, AH etc.). Not all firewalls run NAT, and firewalls inside the
internal network is necessary to separate traffic in different security
zones and inspect traffic between zones.


-Lill-Anita


"Phillip Windell" <@.> wrote in message
news:(E-Mail Removed)...
> "lill" <(E-Mail Removed)> wrote in message
> news:#(E-Mail Removed)...
> > But it is a fact that it might be interesting to use tunnels inside
an
> > internal network too.
>
> I know, but as an illustration, it might be interesting to drive a
> motorcycle up and down the hallway in your house, but that is not what
it is
> design for. There are so many ways out there to do this "right" why do
you
> want to spend so much time, effort, and creativity, to do it "wrong"?
>
> > In my case I will like to have a Remote Access VPN
> > from the remote client to the server running RRAS/ISA in the
perimeter
> > network. In addition to that, I want to have a server-to-server
> > (host-to-host) VPN tunnel from servers running RRAS inside the
internal
> > network and the RRAS/ISA server in the perimeter network. The
traffic
> > from the remote clients are inspected by the RRAS/ISA server before
it
> > is forwarded to the security zone (subnet), through a new tunnel, to
get
>
> Sounds like a Back-to-back DMZ. You can't do what you think there
either.
> You have to run one Tunnel inside the other Tunnel to even get across
a B2B
> DMZ to begin with and there is no way to "inspect" the contents within
the
> Tunnel.
>
> Read about B2B DMZs and VPN by searching with "DMZ" and "VPN" on
> www.isaserver.org
>
> Your intent to do this with firewalls is just simply wrong. Firewalls
run
> NAT along with the rest of what they do,...you don't want NAT...this
is not
> suitable for what you want to do. You control the content of internal
> traffic by using routers (not firewalls) and subnets,...that's half
the
> reason such things exist,...that is what they are for. now if you
find a
> firewall that you can disable NAT and have it work like a router then
that
> would be fine. ISA won't work for the same reason,...it does
"proxying"
> (similar but different than NAT) and you don't want anything
"proxying" the
> requests between subnets in the private system, it creates a "trusted"
and
> "untrusted" subnet and which ever subnet is the lucky one to be
considered
> "untrusted" gets cut off at the knees and no longer functions as a
LAN.
>
> > I do know that security in the LAN is one thing, and Remote Access
VPNs
> > another. But I do need both in my case, so what I am trying to
define is
> > a scenario where both security issues are defined. I also notice
that
>
> Use Routers with ACLs between the subnets. You have not stated exactly
what
> kind of "unwanted" traffic you are wanting to "inspect" .....you may
be
> going through all this hassle for something that is really a non-issue
> anyway....like for example, use a firewall to stop a virus when that
is not
> what stops viruses, AV software does that.
>
>
> --
>
> Phillip Windell [MCP, MVP, CCNA]
> www.wandtv.com
>
>
>

There is no more I can do with this. You have such an odd design and I have
no topology map for either the logical or physical topology and I cannot see
the system with my own eyes. If I worked there I suspect there would end up
being major design changes and I don't think I would have any hope of doing
anything with what you have and how you are trying to do this.


--

Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com


"lill" <(E-Mail Removed)> wrote in message
news:#(E-Mail Removed)...
> By tunneling traffic inside the internal network you do not have to open
> the internal firewalls for all kinds of traffic, only for VPN traffic
> (IKE, AH etc.). Not all firewalls run NAT, and firewalls inside the
> internal network is necessary to separate traffic in different security
> zones and inspect traffic between zones.
>
>
> -Lill-Anita
>
>
> "Phillip Windell" <@.> wrote in message
> news:(E-Mail Removed)...
> > "lill" <(E-Mail Removed)> wrote in message
> > news:#(E-Mail Removed)...
> > > But it is a fact that it might be interesting to use tunnels inside
> an
> > > internal network too.
> >
> > I know, but as an illustration, it might be interesting to drive a
> > motorcycle up and down the hallway in your house, but that is not what
> it is
> > design for. There are so many ways out there to do this "right" why do
> you
> > want to spend so much time, effort, and creativity, to do it "wrong"?
> >
> > > In my case I will like to have a Remote Access VPN
> > > from the remote client to the server running RRAS/ISA in the
> perimeter
> > > network. In addition to that, I want to have a server-to-server
> > > (host-to-host) VPN tunnel from servers running RRAS inside the
> internal
> > > network and the RRAS/ISA server in the perimeter network. The
> traffic
> > > from the remote clients are inspected by the RRAS/ISA server before
> it
> > > is forwarded to the security zone (subnet), through a new tunnel, to
> get
> >
> > Sounds like a Back-to-back DMZ. You can't do what you think there
> either.
> > You have to run one Tunnel inside the other Tunnel to even get across
> a B2B
> > DMZ to begin with and there is no way to "inspect" the contents within
> the
> > Tunnel.
> >
> > Read about B2B DMZs and VPN by searching with "DMZ" and "VPN" on
> > www.isaserver.org
> >
> > Your intent to do this with firewalls is just simply wrong. Firewalls
> run
> > NAT along with the rest of what they do,...you don't want NAT...this
> is not
> > suitable for what you want to do. You control the content of internal
> > traffic by using routers (not firewalls) and subnets,...that's half
> the
> > reason such things exist,...that is what they are for. now if you
> find a
> > firewall that you can disable NAT and have it work like a router then
> that
> > would be fine. ISA won't work for the same reason,...it does
> "proxying"
> > (similar but different than NAT) and you don't want anything
> "proxying" the
> > requests between subnets in the private system, it creates a "trusted"
> and
> > "untrusted" subnet and which ever subnet is the lucky one to be
> considered
> > "untrusted" gets cut off at the knees and no longer functions as a
> LAN.
> >
> > > I do know that security in the LAN is one thing, and Remote Access
> VPNs
> > > another. But I do need both in my case, so what I am trying to
> define is
> > > a scenario where both security issues are defined. I also notice
> that
> >
> > Use Routers with ACLs between the subnets. You have not stated exactly
> what
> > kind of "unwanted" traffic you are wanting to "inspect" .....you may
> be
> > going through all this hassle for something that is really a non-issue
> > anyway....like for example, use a firewall to stop a virus when that
> is not
> > what stops viruses, AV software does that.
> >
> >
> > --
> >
> > Phillip Windell [MCP, MVP, CCNA]
> > www.wandtv.com
> >
> >
> >
>
>