[isalist] IPSec tunnel mode VPN
- From: "Joe Pochedley" <joepochedley@xxxxxxxxx>
- To: <isalist@xxxxxxxxxxxxx>
- Date: Thu, 25 Oct 2007 16:23:14 -0400
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 <mailto:JoePochedley@xxxxxxxxx>
v: 216-206-5505
f: 216-641-7852
Other related posts:
