[isalist] Re: IPSec tunnel mode VPN

Hi Joe,
 
Can you tell me exactly what feature you would like to see included with
the next version re: IPsec tunnel editing. I need a really clear
explanation of the problem so that I can communicate it as precisely as
possible with the ISA dev guys.
 
Thanks!
Tom
 
Thomas W Shinder, M.D.
Site: www.isaserver.org <http://www.isaserver.org/> 
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7 <http://tinyurl.com/3xqb7> 
MVP -- Microsoft Firewalls (ISA)

 


________________________________

        From: isalist-bounce@xxxxxxxxxxxxx
[mailto:isalist-bounce@xxxxxxxxxxxxx] On Behalf Of Joe Pochedley
        Sent: Thursday, November 01, 2007 3: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: