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>