Site-to-Site (-to-site-to-site-to-site-to-site)

Site-to-Site (-to-site-to-site-to-site-to-site)

Post by Jeff Vande » Wed, 03 Mar 2010 08:57:27


SmallCo has just been purchased by BigCo

SmallCo has MO and BOs connected by ISA 2006 EE Site-to-Site VPNs. All sites
are connected to all other sites. Also uses MO ISA for VPN Clients.

BigCo stays "as far away from ISA as possible" (their words), because all
they know is Cisco. However, they will reluctantly let SmallCo keep using
ISA for MO and BO VPN endpoints, provided they all have connectivity to all
of BigCo's many subnets. Here's the diagram that's evolving:

4 SmallCo BO LANs
| | | |
4 SmallCo BO ISA VPN Endpoints
| | | |
Internet
| | | |
SmallCo MO ISA VPN Endpoint/VPN Server--Internet--VPN Clients
|
SmallCo MO LAN
|
Router
|
MPLS
|
Router
|
BigCo MO LAN Subnet--Outbound Internet Access for BC & SC
| | | | | | | | | | | | |
Many Routers
| | | | | | | | | | | | |
Many MPLSs
| | | | | | | | | | | | |
Many Routers
| | | | | | | | | | | | |
Many BigCo LAN Subnets

What I think I know of ISA tells me that SmallCo BOs and VPN Clients will
never see packets from BigCo because SmallCo BO ISAs will drop them as
spoofed.

If I (like it or not) disable spoof detection, will this diagram work?

Do I add BigCo address ranges to the MO VPN Networks at the BO ISAs? On the
Internal Network at the MO ISA?

Anything else it will take to make this design work?


--
Jeff Vandervoort
JRVsystems
http://www.yqcomputer.com/
 
 
 

Site-to-Site (-to-site-to-site-to-site-to-site)

Post by Phillip Wi » Thu, 04 Mar 2010 02:43:35

o way you are going to make a diagram in a text message make sense :-)

1. Hang their Cisco VPN box "off the side" of you Main Site ISA on its own
Nic and "new" subnet.

2. The new Network defintion when created will be set to "internal" as the
Type. Relationship will be "routed".

3. The IP Range will be new but is generally not relevant, just don't create
a conflict with anything else in use. The Range can even be a 2-host 30bit
subnet like a Point-to-Point link would have. But then after that you will
add *ALL* the BigCo IP Ranges to this Network Defintion as well as this new
one you created.

4. Then create a Static Rotue for all the BigCo's subnets that uses this
"new nic" as the Gateway.

5. Create Access Rules to handle the traffic between Internal, your other
Remote Networks, and the new Network Defintion you created.

That pretty much covers your Main ISA.

The ISAs at your other Sites will:

1. Add the same BigCo subnets to the Netwrok definiton that they *already*
use to represent you Main office.

2. Create Access Rules or modify the exisiting Access Rules for traffic to
the BigCo. Remember that when traffic has to cross more than one ISA to get
somewhere,...*all* the involved ISAs have to say "Yes" to the traffic. If
there is a "No" anywhere along the way it will fail.

3. I do not believe that any Static routes are needed because the VPN uses a
"Virtual Nic" that is created when the VPN is activated and it runs "over
the top" of the External Nic that is already there. So as long as the
Destiantion Address Ranges are in the Network Definiton,...the routing
should be automatic,...in fact it is eaither automatic or it just doesn't
exist,...this is no manual way, ..it does not exist,..don't ask.
Therefore,...no Static Routes.

Your ISA at the main site will look like this diagram. Just "pretend" that
the router hanging off the side in the Diagram is the BigCo's Cisco VPN box.
Your existing VPN Links to your original remote sites are not reflected in
the diagram,...but they run "over-the-top" of the regular Internet
link,...they have no direct physical relationship to the BigCo's Cisco VPN
box.

http://i591.photobucket.com/albums/ss360/pwindell/Drawing1.jpg

Think simple!! Do not over-think it!! It is a simpler design than what
most people would expect it to be.


--
Phillip Windell

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------
Technet Library
ISA2004
http://technet.microsoft.com/en-us/library/cc302436(TechNet.10).aspx
ISA2006
http://technet.microsoft.com/en-us/library/bb898433(TechNet.10).aspx

Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/ISA2004_AccessRules.html

Troubleshooting Client Authentication on Access Rules in ISA Server 2004
http://download.microsoft.com/download/9/1/8/918ed2d3-71d0-40ed-8e6d-fd6eeb6cfa07/ts_rules.doc

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.mspx

Microsoft ISA Server Partners: Partner Hardware Solutions
http://www.microsoft.com/forefront/edgesecurity/partners/hardwarepartners.mspx
-----------------------------------------------------


"Jeff Vandervoort" <jeffv at jrvsystems dot com> wrote in message
news: XXXX@XXXXX.COM ...



 
 
 

Site-to-Site (-to-site-to-site-to-site-to-site)

Post by Jeff Vande » Sat, 06 Mar 2010 03:11:41

hanks, Phillip, that was EXTREMELY helpful. The key was the BO Network
definition for the MO.

I've just kinda-sorta modeled it by adding the VPN Client address range to
the MO's Enterprise Network, which gave me connectivity to the BO LANs by
making a VPN Client connection to the MO ISA.

Believe me, I've tried every other possible permutation of Network
definitions to be able to do this, and nothing worked! It didn't matter for
VPN users because they only needed MO resources. It was desirable only for
remote admin use. But this does work, even with spoof detection enabled.

You're right: The answer was right in front of me, and MUCH simpler than I
thought! However...

I've also posted this question to the ISA private MS Partner newsgroups. MS
PS told me this is not a supported config with ISA; that I have to connect
by VPN Client to the remote ISA to access the remote LAN, and I have to have
either a (separate) VPN or physical interface on each ISA for each BigCo
site. And politically, that ain't gonna happen.

I know you can't speak for Microsoft, but any insight as to what their
concern is? I can see that it makes access control, monitoring and packet
inspection between sites a lot less granular, and forces all traffic through
the MO ISA. But while we may well inspect BigCo packets, treating all of
BigCo as one Network is OK for that purpose. They're responsible for what
happens between their sites. And we've already accepted all traffic flowing
through MO's (fat) pipe to BigCo, so that's moot.

No one wants to go with an unsupported config, but we all do from time to
time. Any other ramifications?

--
Jeff Vandervoort
JRVsystems
http://www.jrvsystems.com

"Phillip Windell" < XXXX@XXXXX.COM > wrote in message
news:OfSw0# XXXX@XXXXX.COM ...
 
 
 

Site-to-Site (-to-site-to-site-to-site-to-site)

Post by Phillip Wi » Sat, 06 Mar 2010 05:37:40

don't think you did what I said.

You don't add the "VPN Client Address Range" to anything,...it is what it is
and it stays what it stays. Don't try to "out smart" the system,...you
will always loose, the system will always win.

Do it like I described and it should work.

The Access Rules will do exactly what they say they will do,...so design
them correctly with the correct Source and Destiantion in the Rules.

If a Remote Access user dials in at the ISA and has to get to a different
Remote Office then an Access Rule has to specifiy that.

From: Internal, VPN Users Network, <plus other Office Networks>
To: Internal, VPN Users Network, <plus other Office Networks>
Protocol: <whatever>
Users: <whatever>

Network Rules:
Don't forget the Network Rules. They are not the same thing as Access Rules.
They are automatically "bi-directional" when the relathionship is set to
"routed"
So for the Remote Access VPN Users you will need:

From: VPN CLients Network
To: RemoteSite1, RemoteSite2, Remotesite3 <you get the point>
Relationship = "routed"


--
Phillip Windell

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------




"Jeff Vandervoort" <jeffv at jrvsystems dot com> wrote in message
news: XXXX@XXXXX.COM ...


 
 
 

Site-to-Site (-to-site-to-site-to-site-to-site)

Post by Jeff Vande » Sat, 06 Mar 2010 17:16:00

can't do what you said, yet; we don't yet have a connection to BigCo and I
haven't had time to model it with VMs.

But what I *COULD* do--very easily--without even being onsite--was test with
a VPN client connection to the MO to see if I could get connectivity to the
BO. In the past, that has always failed with the BO ISA showing spoof errors
in the logs. All the other pieces (Network Rules, Access Rules) were in
place. All I lacked was the correct definition of the MO Network on the BO
ISA. So the MO Network definition on BO ISAs was the magic bullet answer.

With that in place, no spoof errors from my 2nd-hop VPN Client connection,
and I have connectivity to all sites, at least via VPN Client, without
connecting directly to the BO ISAs. That strongly suggests it will also work
for BigCo connectivity when I get the site-to-site pieces for it in place in
a few days, including an appropriate Network definition.

That doesn't mean I'm going to try using a VPN client for a site-to-site, or
whatever it was you thought I was proposing!

Speaking of "outsmarting the system", I mentioned that MS Partner Support
reports that this is an unsupported configuration. I had asked about that
in my prior post to you. MS wants a separate VPN or physical connection to
each remote site from each remote site. Or in the case of VPN Clients, from
each VPN Client to each VPN Server.

I speculated about what we're missing by going with this config instead of
MS's prescribed config, but if you know of other ramifications, I'd be
interested in hearing them.

--
Jeff Vandervoort
JRVsystems
http://www.jrvsystems.com

"Phillip Windell" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...
 
 
 

Site-to-Site (-to-site-to-site-to-site-to-site)

Post by Phillip Wi » Wed, 10 Mar 2010 00:29:32


I don't think you can simulate it with a Remote Access VPN Connection. They
do not work by the same principles.
You would need a Virtual LAB on powerful enough hardware to run 3 ISAs with
3 DCs (to simulate authetication). Arange them in pairs (DC-ISA) on
different Networks. Create a S2S-VPN between ISA1 and ISA2,...and then
another between ISA2 and ISA3,...so ISA2 would be the "Center" ISA. Then
try to get the DC behind ISA1 to communicate with the DC behind ISA3.


Yea. I saw that. Sounds like they are saying that the Site2Site VPNs have to
be a "Full Mesh" model.
That is the first I heard of that,..but then what you are wanting to do is
the first I heard of anyone doing that too. They are probably right,...they
know more about their product than I do. So I guess what I am suggesting
amounts to trying to "outsmart the system" as well. However MS saying that
something is not supported does not mean it won't work,...it means they
consider it to be undependable and unstabile and do not want to risk being
responsible for supporting it.


--
Phillip Windell

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------
Technet Library
ISA2004
http://www.yqcomputer.com/ (TechNet.10).aspx
ISA2006
http://www.yqcomputer.com/ (TechNet.10).aspx

Understanding the ISA 2004 Access Rule Processing
http://www.yqcomputer.com/

Troubleshooting Client Authentication on Access Rules in ISA Server 2004
http://www.yqcomputer.com/

Microsoft Internet Security & Acceleration Server: Partners
http://www.yqcomputer.com/

Microsoft ISA Server Partners: Partner Hardware Solutions
http://www.yqcomputer.com/
-----------------------------------------------------
 
 
 

Site-to-Site (-to-site-to-site-to-site-to-site)

Post by Jeff Vande » Mon, 15 Mar 2010 08:02:56

gt; I don't think you can simulate it with a Remote Access VPN Connection.

But Phillip, spoof detection does. The spoof detection problem was my only
concern about this diagram, and was solved by defining the remote MO network
to include the VPN clients. My past experience trying to make VPN clients
connect "through" the mesh instead of outside of it was the big concern in
my original post. It kept running foul of spoof detection.

And that Network definition was the ONLY piece missing in my design.
Likewise, had I not included the BigCo subnets in the remote MO Network
definition, incoming BigCo packets would be dropped as spoofed. Instead, it
now works (BigCo & SmallCo are all connected as of the 10th). I thought I
was going to have to disable spoof detection because I believed MS PS's
company line. But that was not necessary. Just needed to rethink the MO
Network definition for the remote ISAs.

So thanks for your help; the remote MO Network address setup was OBVIOUSLY
AND ABSOLUTELY the only missing link for both VPN Clients and BigCo and I
appreciate the insight.

And an aside: I'm glad to say karma caught up with BigCo's Cisco fanboy
network engineer, who has been dismissive of SmallCo's little ISA firewalls.
He said all his routing tables were set up for us and then went on vacation,
figuring any problems would be on our side. Well, that turned out to be
wrong. We reached him on vacation and he had to VPN in and fix his end. As
he did so, BigCo/SmallCo connectivity to each site came up without further
intervention on our side. Meanwhile, we, and ISA, Just WorkedT. I'm sure
I'll pay for it later, and he'll catch me in a mistake. But it was fun.


Agreed about the "doesn't mean it won't work" part. The SmallCos of this
world rely on "unsupported" configs for lots of stuff--out of necessity!
Sometimes the BigCos, for that matter.

But undependable and unstable? Hmmm; what else could be at issue? MS is not
above wanting to sell more ISA licenses. And full mesh, while defensible on
the grounds of being a superior topology, and allowing more granular
control, has that other, beneficial side effect of selling more ISA
licenses. Here, SmallCo's could either keep all but one of our ISA licenses,
or abandon all of them, the latter of which BigCo would have much preferred.
We certainly weren't going to be allowed to put an ISA EE at each BigCo
subnet. So at least in this instance, MS came out a winner with the
"unsupported" design. But as well as it's working, at least after BigCo
fixed their routing tables, I doubt we'll have any problems.

--
Jeff Vandervoort
JRVsystems
http://www.jrvsystems.com

"Phillip Windell" < XXXX@XXXXX.COM > wrote in message
news:#2u$# XXXX@XXXXX.COM ...
 
 
 

Site-to-Site (-to-site-to-site-to-site-to-site)

Post by Phillip Wi » Thu, 18 Mar 2010 00:56:19


My favorite part of the story!!


--
Phillip Windell

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------