[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

         

Other related posts: