[isalist] Re: IPSec tunnel mode VPN
- From: "Joe Pochedley" <joepochedley@xxxxxxxxx>
- To: <isalist@xxxxxxxxxxxxx>
- Date: Fri, 2 Nov 2007 08:49:58 -0400
Thor,
I've tried to be clear. I understand with the couple extra sidelights
and gyrations Tom and I went through to get to this point, how the water
could be a bit muddied though.
I'm not sure how the PIX network is defined incorrectly? Is it a
non-standard configuration? Yep. However, what about that makes it
incorrect? The service provider who's going to be doing the monitoring
(they're the one with the PIX), have other clients. If they defined the
network/tunnel to match our definition, they would have an overlap
between our network and other clients. (They're establishing multiple
tunnels on the same PIX.) The tightly defined tunnel's network
definition allows them to avoid the overlap with other clients. From
their point of view, such a definition is the easy solution. Although
it is the easy solution, and a bit out of the ordinary, I'm not sure
what makes it patently incorrect? (Note, I'm not saying you're wrong in
your assessment. Only now it's my turn to be confused.)
And finally - "PIX host-by-host addressing doesn't necessarily mean you
have to do it the same way on ISA"
You're right, you don't have to do it the same way. However, the
problem that's created with the different network definitions is that
quick mode authentication fails if the ISA tries to establish the
tunnel. However, the ISA will gladly accept the PIX's network
definition and the PIX can establish the tunnel. So, again, the problem
is more just an annoyance at this point.
Joe P
From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx]
On Behalf Of Thor (Hammer of God)
Sent: Thursday, November 01, 2007 10:29 PM
To: isalist@xxxxxxxxxxxxx
Subject: [isalist] Re: IPSec tunnel mode VPN
Actually, I just say things like "I'm confused" when I'm trying to be
nice to the OP when they are not being very clear :-p So, I won't hold
it against you if you don't hold it against me ;)
The issue is that you've got the PIX network defined incorrectly, which
makes you have to define it incorrectly elsewhere -- asking for features
in ISA that help one fix poorly configured networks behind Cisco
products isn't really feasible. So, no, it's not really an ISA problem
at all. The only reason ISA comes into this is where you need it to be
the endpoint yet also define rules against the remote network within a
different ISA network context. But even the way you've described the
remote PIX host-by-host addressing doesn't necessarily mean you have to
do it the same way on ISA - you can still define a "single" network to
ISA that comprises all the remote hosts in a single subnet if you want
to - it's just about routing at that point.
But, if you are saying that you want the other network hosts to "appear
as internal hosts" then just create your IPSec tunnel on an XP box
somewhere and route through that guy and be done with it.
t
From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx]
On Behalf Of Joe Pochedley
Sent: Thursday, November 01, 2007 1:55 PM
To: isalist@xxxxxxxxxxxxx
Subject: [isalist] Re: IPSec tunnel mode VPN
Thor,
Confusion is a standard state for you, is it not? (Sorry, I've lurked
on this list for a loooooong time.. I just don't get much of a chance to
contribute because the rest of you are just so darn smart... So I had to
take my one opportunity to jab at you. Don't hold it against me!) All
joking aside.....
Yes, Tom said it could be done, and I agree that it could. However, I
did explain why in my situation it would be difficult and impractical to
define the network/clients in such a fashion (summary: non-contiguous
block of IP addresses).... In that regard, I'm the one being stubborn
with a PITA configuration I suppose.
I have defined a IPSEC tunnel on the ISA server and am not using L2TP.
I basically followed the instructions here:
http://www.microsoft.com/technet/isa/2004/plan/ipsecvpn.mspx
Why is this an ISA problem? Well, if the PIX can do it, then ISA (the
superior product) should be able to as well. Yeah, well, the PIX can
allow you to screw up your security, so the ISA should too, eh? J
Again, joking aside... I guess it's not an ISA problem, as we've
already agreed it can be done. As for the Advanced Tunnel Editing
comment... I was just hoping for an easier way to work around the
issue, possibly by defining the "Local Network 'Internal' Subnets" (as
ISA calls them) manually - outside the ISA 'Networks' configuration.
Joe P
From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx]
On Behalf Of Thor (Hammer of God)
Sent: Thursday, November 01, 2007 2:43 PM
To: isalist@xxxxxxxxxxxxx
Subject: [isalist] Re: IPSec tunnel mode VPN
A bit late, but I'm kind of confused... What exactly are you asking for
when you want "advanced tunnel editing?" And I'm not sure why you
"lament" ISA not being able to granular define a network - like Tom
said, you can have a network of a single IP - that's as "granular" as it
gets. In your OP you said you "of course, need to define the 'network'
as our internal network." Why "of course?" Why does it have to be
defined as your internal network? Just so you can "monitor" these
units? Further, you say "the PIX can establish the connection to your
network" but you think the "PIX end is not accepting the network as
defined." If so, how is this and ISA issue?
Lastly, what exactly do you mean by "IPSec tunnel mode VPN?" You've
defined an IPSec policy on the ISA box itself and are connecting to the
remote PIX in tunnel mode? Or you've got an L2TP VPN configured via
RRAS (which I've seen some people confuse with an IPSec tunnel). The
link you provided was for a point-to-point VPN between the ISA and a
remote host, not an "IPSec tunnel mode VPN."
t
From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx]
On Behalf Of Joe Pochedley
Sent: Tuesday, October 30, 2007 2:05 PM
To: isalist@xxxxxxxxxxxxx
Subject: [isalist] Re: IPSec tunnel mode VPN
That's the rub... The addresses can't co-exist in two networks. I
understand the reasoning for this, hence my comment earlier in the
thread about doing something stupid (by defining two networks with
overlapping IP's, you can create a BIG hole in network security if
you're not careful)...
Anyhow, the 'network' on the PIX side is defined as multiple individual
hosts. The hosts are in a non-contiguous block of IP addresses
(example: 10.1.1.2, 10.1.1.3, 10.1.1.20, 10.1.1.21, 10.1.2.28, with
hosts in between which _aren't_ in the PIX list....). As such, I would
have to re-define my 'Internal' network on the ISA side as about 50
different 'networks' so I could then come up with a matching set of
individual hosts for the PIX.
So in short, can it be done? Yep, I suppose so. Is it elegant? Not by
a long shot... I was honestly just hoping there was some way to more
manually define the tunnel parameters, but I suppose there's not.
So anyway, I should just drop the matter. It's a non-standard situation
which it appears only a handful of people have need of.... (As I
pointed out earlier, I'm not alone:
http://forums.isaserver.org/m_2002054535/mpage_1/key_ipsec/tm.htm#200205
5269 )
Dr. Tom, thanks again for your time! Maybe if you can see some value,
you can put in advanced tunnel editing as a feature request for ISA 2008
(or whatever the next version turns out to be)?
Joe P
From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx]
On Behalf Of Thomas W Shinder
Sent: Tuesday, October 30, 2007 2:25 PM
To: isalist@xxxxxxxxxxxxx
Subject: [isalist] Re: IPSec tunnel mode VPN
You can define a network with a single IP address if you like. Just make
sure that IP address isn't included in any other ISA Firewall Network.
Thomas W Shinder, M.D.
Site: www.isaserver.org <http://www.isaserver.org/>
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
MVP -- Microsoft Firewalls (ISA)
________________________________
From: isalist-bounce@xxxxxxxxxxxxx
[mailto:isalist-bounce@xxxxxxxxxxxxx] On Behalf Of Joe Pochedley
Sent: Tuesday, October 30, 2007 1:08 PM
To: isalist@xxxxxxxxxxxxx
Subject: [isalist] Re: IPSec tunnel mode VPN
Amy,
The difference lies in the two different 'network' definitions
between the setup of the ISA and PIX. As such, as things are configured
now, the PIX can start the tunnel, but the ISA cannot due to these
differences. In short, I'm lamenting the fact that the ISA cannot
define the network as granularly as the PIX which leads to
interoperability issues.
Joe P
From: isalist-bounce@xxxxxxxxxxxxx
[mailto:isalist-bounce@xxxxxxxxxxxxx] On Behalf Of Amy Babinchak
Sent: Friday, October 26, 2007 5:30 PM
To: isalist@xxxxxxxxxxxxx
Subject: [isalist] Re: IPSec tunnel mode VPN
I have an IPSec tunnel connected to a PIX. Didn't have any
problem with that. Where's the issue?
Amy
From: isalist-bounce@xxxxxxxxxxxxx
[mailto:isalist-bounce@xxxxxxxxxxxxx] On Behalf Of Joe Pochedley
Sent: Friday, October 26, 2007 5:21 PM
To: isalist@xxxxxxxxxxxxx
Subject: [isalist] Re: IPSec tunnel mode VPN
Tom,
I understand what you're saying... Being able to granularly
define the 'network' provides no extra level of security... Properly
implemented firewall rules provide much better control over who and what
can pass through the connection... Access <> security, though access is
a part of security, and all pieces of security should be controlled
through the firewall rules.... I can agree with that. And for that, and
other reasons, you'd have to pry my ISA out of my cold, dead hands
before I'd replace it with anything like a PIX.
However, point on security being well taken, what I really want
to discuss is a point of flexibility... I still can't get around the
limitation or inability of ISA to interoperate with a device that can
define granular IPSEC 'network' definitions. The remote side won't take
the ISA's broadly defined IPSEC network definition, and as such the ISA
can't establish a tunnel. It seems almost as if this was an artificial
limitation, or a simplification to keep folks from making dumb
mistakes...?
Thanks for your time.
Joe P
From: isalist-bounce@xxxxxxxxxxxxx
[mailto:isalist-bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder
Sent: Friday, October 26, 2007 4:00 PM
To: isalist@xxxxxxxxxxxxx
Subject: [isalist] Re: IPSec tunnel mode VPN
I don't' agree. Security is set at firewall policy, not at the
definition of ISA Firewall Networks. There's no reasonable expectation
to think that ISA Firewall Networks should enforce firewall policy.
From: isalist-bounce@xxxxxxxxxxxxx
[mailto:isalist-bounce@xxxxxxxxxxxxx] On Behalf Of Joe Pochedley
Sent: Friday, October 26, 2007 12:37 PM
To: isalist@xxxxxxxxxxxxx
Subject: [isalist] Re: IPSec tunnel mode VPN
I understand what you're saying, Tom. Really, I do. And as I
noted below I will be setting up firewall rules / policy on the
connection.
However, I always thought the best security was through layers
of security. As such, I'd view the ability to more tightly define the
'networks' as just another layer of security.
Agree to disagree I suppose?
That argument aside, it's still troubling that this limitation
prevents me from establishing the connection from this side.
Joe P
From: isalist-bounce@xxxxxxxxxxxxx
[mailto:isalist-bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder
Sent: Thursday, October 25, 2007 6:30 PM
To: isalist@xxxxxxxxxxxxx
Subject: [isalist] Re: IPSec tunnel mode VPN
No, "tightness" is done by creating firewall policy, not by
defining networks.
Thomas W Shinder, M.D.
Site: www.isaserver.org <http://www.isaserver.org/>
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
MVP -- Microsoft Firewalls (ISA)
________________________________
From: isalist-bounce@xxxxxxxxxxxxx
[mailto:isalist-bounce@xxxxxxxxxxxxx] On Behalf Of Joe Pochedley
Sent: Thursday, October 25, 2007 3:23 PM
To: isalist@xxxxxxxxxxxxx
Subject: [isalist] IPSec tunnel mode VPN
I'm trying to set up an IPSEC tunnel with a company
we're partnering with to do some 24hr monitoring of our servers...
(Short version: management wants an eye on some servers that now need to
be running 24/7, we don't have a 24/7 IT staff, at least not on site...
J ) This is my first pass at setting up IPSEC tunnels in anything but
an ISA to ISA config, and even that was more for playing and not for
production.....so I freely admit that I'm by no means an IPSEC expert!
Anyhow, trying to set up a IPSEC tunnel from our ISA
2004 Server to their Cisco (Syphco) PIX. They've got the IPSEC IKE
configuration on the PIX defining the 'networks' as the individual hosts
that need to be monitored. As they're monitoring others clients off the
same hardware/configs, they can't define the network tunnels with the
same overly broad stroke as our ISA's 'Internal' network is defined
(10.1.0.0/16... Way bigger than we need, but anyhow.....)
On the ISA side, we've of course need to define the
'network' as our internal network. The IPSEC definition includes the
'internal' network as the source network. I can't define individual
hosts like the Cisco guys can. From a security standpoint, wouldn't it
make sense to allow that 'network' definition to be as tight as
possible, even down to the individual client level? I guess maybe
there's one or two things the Cisco guys do better, but I digress..
Now, the PIX can establish the connection to our network
and then traffic can flow back and forth from the defined hosts.
Everything is happy, we can get the monitoring done, etc etc... I can
apply a firewall rule to the client set being monitored, and only allow
the proper protocols to flow to and from that set, so things should be
reasonably secure.
However, I can't establish the tunnel from the local
side (our internal / ISA side) of the network. The error that I
believe is causing the problem is the "notify: NO-PROPOSAL-CHOSEN" which
I believe tells me that the PIX end isn't accepting the network as I
have it defined? (I'll attach a snippet of the Oakley.log file at the
end of the message.)
While being unable to start the tunnel from this side
isn't a show stopper for our current situation, I could see it being an
issue elsewhere... It seems to me that the IPSEC implementation on the
ISA isn't quite as robust as it could be. I'm sure it serves the need
for 98% of folks, and that's all we can ask for, right?
So finally to the questions: Do I just grin and bear
this limitation? Or..Is there some way to work around it? OR... Am I
just WAY off base and missing the obvious?
Sorry for the long message.
Joe Pochedley
PS: Who uses PS in an email? Well I already had the
email written, and figured why waste a good email, when I found this:
http://forums.isaserver.org/m_2002054535/mpage_1/key_ipsec/tm.htm#200205
5269
Seems like I'm not the only one who's had this problem,
so maybe I'm not totally crazy.
Snippet of Oakley.log file from the Windows / ISA
box....
10-25: 14:47:42:686:7f8 Acquire from driver: op=0000080E
src=10.1.2.28.0 dst=172.16.150.100.0 proto = 0, SrcMask=255.255.0.0,
DstMask=255.255.255.0, Tunnel 1, TunnelEndpt=206.x.x.x Inbound
TunnelEndpt=64.x.x.x
10-25: 14:47:42:701:c344 Starting Negotiation: src =
64.x.x.x.0500, dst = 206.x.x.x.0500, proto = 00, context = 0000080E,
ProxySrc = 10.1.0.0.0000, ProxyDst = 172.16.150.0.0000 SrcMask =
255.255.0.0 DstMask = 255.255.255.0
10-25: 14:47:42:701:c344 QM PolicyName: ISA Server
NetServe365 QM Policy dwFlags 0
10-25: 14:47:42:701:c344 QMOffer[0] LifetimeKBytes 0
LifetimeSec 0
10-25: 14:47:42:701:c344 QMOffer[0] dwFlags 0 dwPFSGroup
0
10-25: 14:47:42:701:c344 Algo[0] Operation: ESP Algo:
Triple DES CBC HMAC: MD5
10-25: 14:47:42:701:c344 GetSpi: src =
172.16.150.0.0000, dst = 10.1.0.0.0000, proto = 00, context = 0000080E,
srcMask = 255.255.255.0, destMask = 255.255.0.0, TunnelFilter 1
10-25: 14:47:42:701:c344 Setting SPI 1690425572
10-25: 14:47:42:701:c344 constructing ISAKMP Header
10-25: 14:47:42:701:c344 constructing HASH (null)
10-25: 14:47:42:701:c344 constructing SA (IPSEC)
10-25: 14:47:42:701:c344 constructing NONCE (IPSEC)
10-25: 14:47:42:701:c344 constructing ID (proxy)
10-25: 14:47:42:701:c344 constructing ID (proxy)
10-25: 14:47:42:701:c344 constructing HASH (QM)
10-25: 14:47:42:701:c344
10-25: 14:47:42:701:c344 Sending: SA = 0x0011D980 to
206.x.x.x:Type 2.500
10-25: 14:47:42:701:c344 ISAKMP Header: (V1.0), len =
148
10-25: 14:47:42:701:c344 I-COOKIE fad3b3c540877a2f
10-25: 14:47:42:701:c344 R-COOKIE d1a85d37e8f69605
10-25: 14:47:42:701:c344 exchange: Oakley Quick Mode
10-25: 14:47:42:701:c344 flags: 1 ( encrypted )
10-25: 14:47:42:701:c344 next payload: HASH
10-25: 14:47:42:701:c344 message ID: 17da6134
10-25: 14:47:42:701:c344 Ports S:f401 D:f401
10-25: 14:47:43:858:90 retransmit: sa = 0011D980 centry
000EBFF0 , count = 1
10-25: 14:47:43:858:90
10-25: 14:47:43:858:90 Sending: SA = 0x0011D980 to
206.x.x.x:Type 2.500
10-25: 14:47:43:858:90 ISAKMP Header: (V1.0), len = 148
10-25: 14:47:43:858:90 I-COOKIE fad3b3c540877a2f
10-25: 14:47:43:858:90 R-COOKIE d1a85d37e8f69605
10-25: 14:47:43:858:90 exchange: Oakley Quick Mode
10-25: 14:47:43:858:90 flags: 1 ( encrypted )
10-25: 14:47:43:858:90 next payload: HASH
10-25: 14:47:43:858:90 message ID: 17da6134
10-25: 14:47:43:858:90 Ports S:f401 D:f401
10-25: 14:47:43:967:c344
10-25: 14:47:43:967:c344 Receive: (get) SA = 0x0011d980
from 206.210.85.4.500
10-25: 14:47:43:967:c344 ISAKMP Header: (V1.0), len =
108
10-25: 14:47:43:967:c344 I-COOKIE fad3b3c540877a2f
10-25: 14:47:43:967:c344 R-COOKIE d1a85d37e8f69605
10-25: 14:47:43:967:c344 exchange: ISAKMP
Informational Exchange
10-25: 14:47:43:967:c344 flags: 1 ( encrypted )
10-25: 14:47:43:967:c344 next payload: HASH
10-25: 14:47:43:967:c344 message ID: 6b4f0a42
10-25: 14:47:43:967:c344 processing HASH (Notify/Delete)
10-25: 14:47:43:967:c344 processing payload NOTIFY
10-25: 14:47:43:967:c344 notify: NO-PROPOSAL-CHOSEN
10-25: 14:47:45:858:90 retransmit: sa = 0011D980 centry
000EBFF0 , count = 2
10-25: 14:47:45:858:90
10-25: 14:47:45:858:90 Sending: SA = 0x0011D980 to
206.x.x.x:Type 2.500
Joe Pochedley
Network & Telecommunications Manager
The North American Mfg. Co.
email: JoePochedley@xxxxxxxxx
v: 216-206-5505
f: 216-641-7852
ExchangeDefender Message Security: Check Authenticity
<http://www.exchangedefender.com/verify.asp?id=l9QLVEp9003270&from=amy@h
arborcomputerservices.net>
Other related posts:
