ISA & Third party VPN site to site Over Ipsec PROBLEM (Full Version)

All Forums >> [ISA Server 2004 Firewall] >> VPN



Message

Nicomaco -> ISA & Third party VPN site to site Over Ipsec PROBLEM (4.Jun.2008 11:56:27 AM)

Hi!
 
Im trying to setup a site to site vpn over ipsec between an isa Server 2004 std and a router 3com officeconnect.
 
[image]http://www.euzkalnik.com.ar/isa%20problem.jpg[/image]



Below I put the resume of the ISA ipsec configuration.
 
 
 
Extremo del túnel local: 192.168.0.4  (isa external interface) connected to a router with static public IP 200.x.x.x
Extremo del túnel remoto: 190.y.y.y (public static IP of the router)
 
 
Parámetros IKE Fase I:
    Modo: modo principal
    Cifrado: DES
    Integridad: SHA1
    Grupo Diffie-Hellman: Grupo 1 (768 bits)
    Método de autenticación: secreto previamente compartido (test1111)
    Tiempo de vida de la asociación de seguridad: 28800 segundos
 
Parámetros IKE Fase II:
    Modo: modo de túnel ESP
    Cifrado: DES
    Integridad: SHA1
    Confidencialidad directa perfecta: activada
    Grupo Diffie-Hellman: Grupo 1 (768 bits)
    Regeneración de clave Time: activada
    Tiempo de vida de la asociación de seguridad: 28800 segundos
    Regeneración de clave KByte: desactivada
 
Subredes IP de la red remota "VPNSitetosite":
    Subred: 192.168.2.0/255.255.255.0
 
Subredes IP de la red local "Interna":
    Subred: 192.168.1.0/255.255.255.0
 
 ---------------------------------------------
 

The problem I have is that I cannot make it works. Below you can see the 3com officeconnect router in the branch office:
 


Jun 3 15:03:45 localhost kernel: IKE: IKE --Start Phase 1 negotiation with peer 200.x.x.x
Jun 3 15:03:45 localhost kernel: IKE: IKE -- RemoteGateway ID: IPV4_ADDR--200.x.x.xPresharedKey:test1111
Jun 3 15:03:45 localhost kernel: IKE: IKE -- Protocol -- PROTO_ISAKMP
Jun 3 15:03:45 localhost kernel: IKE: IKE -- Transform -- KEY_IKE
Jun 3 15:03:45 localhost kernel: IKE: IKE -- Encryption -- DES_CBC
Jun 3 15:03:45 localhost kernel: IKE: IKE -- Hash -- SHA_HASH
Jun 3 15:03:45 localhost kernel: IKE: IKE -- My ID: IPV4_ADDR--190.y.y.y PresharedKey:test1111
Jun 3 15:03:45 localhost kernel: IKE: IKE -- Authentication -- PRESHARED_KEY
Jun 3 15:03:45 localhost kernel: IKE: IKE -- LifeType -- SECONDS
Jun 3 15:03:45 localhost kernel: IKE: IKE -- LifeDuration -- 28800
Jun 3 15:03:45 localhost kernel: IKE: IKE -- GroupDescription -- MODP_768
Jun 3 15:03:45 localhost kernel: IKE: IKE -- MainMode Exchange Selected
Jun 3 15:03:45 localhost kernel: IKE: IKE -- MainMode -- initiator sent out message1 to 200.x.x.x, port 500->500.
Jun 3 15:03:45 localhost kernel: IKE: IKE -- MainMode -- initiator received response message1 from 200.x.x.x, port 500->500.
Jun 3 15:03:45 localhost kernel: IKE: IKE -- Proposal 1 -- protocol PROTO_ISAKMP, with 1 transforms
Jun 3 15:03:45 localhost kernel: IKE: IKE -- Transform 1 -- KEY_IKE, index = 1
Jun 3 15:03:45 localhost kernel: IKE: IKE -- Encryption -- DES_CBC
Jun 3 15:03:45 localhost kernel: IKE: IKE -- Hash -- SHA_HASH
Jun 3 15:03:45 localhost kernel: IKE: IKE -- GroupDescription -- MODP_768
Jun 3 15:03:45 localhost kernel: IKE: IKE -- Authentication -- PRESHARED_KEY
Jun 3 15:03:45 localhost kernel: IKE: IKE -- LifeType -- SECONDS
Jun 3 15:03:45 localhost kernel: IKE: IKE -- LifeDuration -- 28800
Jun 3 15:03:45 localhost kernel: IKE: IKE -- Peer supports NAT-T, on draft 2
Jun 3 15:03:45 localhost kernel: IKE: IKE -- Peer IP seen: 200.x.x.x
Jun 3 15:03:45 localhost kernel: IKE: IKE -- Local IP: 190.y.y.y
Jun 3 15:03:45 localhost kernel: IKE: IKE -- MainMode -- initiator sent out message2 to 200.x.x.x, port 500->500.
Jun 3 15:03:46 localhost kernel: IKE: IKE -- MainMode -- initiator received response message2 from 200.x.x.x, port 500->500.
Jun 3 15:03:46 localhost kernel: IKE: IKE -- My ID in payload: IPV4_ADDR--190.y.y.y
Jun 3 15:03:46 localhost kernel: IKE: IKE -- MainMode -- initiator sent out message3 to 200.x.x.x, port 500->500.
Jun 3 15:03:46 localhost kernel: IKE: IKE -- MainMode -- initiator received response message3 from 200.x.x.x, port 500->500.
Jun 3 15:03:46 localhost kernel: IKE: IKE -- RemoteGateway ID in payload: IPV4_ADDR--192.168.0.4
Jun 3 15:03:46 localhost kernel: IKE: IKE --INVALID_ID_INFORMATION (0x12) -- peer 200.x.x.x
Jun 3 15:03:46 localhost kernel: IKE: IKE --Sending Notification INVALID_ID_INFORMATION (0x12) to peer 200.x.x.x
 
----

 
Also I configured a port fordwarding (udp 500, udp 4500) on  router 200.x.x.x (main office router) to the ISA external interface 192.168.0.4).

Another question…:
There s another port required?
 
On ISA Server I setup a network relationship between the internal LAn and the "VPNSitetosite".  
 
 
Any help, please!!
 
 



justmee -> RE: ISA & Third party VPN site to site Over Ipsec PROBLEM (4.Jun.2008 1:03:59 PM)

Hi Rafael,
Did you enabled NAT-T on the 3com ?
I see it says something about that the NAT-T VID received from ISA. Just to make sure you did so.
Did you configured manually the Main Mode ID on the 3com router ?
I see that the 3com router expects the MM ID to be the public IP address of the router in front of ISA.
This causes IKE MM negotiations to fail.
By the way, why are you using DH Group1 and DES ?
They provide very little privacy.
Are you facing some cryptographic restrictions ?
Regards!



Nicomaco -> RE: ISA & Third party VPN site to site Over Ipsec PROBLEM (4.Jun.2008 3:10:21 PM)

Hi justmee, thanks for your reply.

MM.... I will check the NAT-T on the 3com router.
Yes, I configured the main mode id manually.

Yes, I also see that the 3com router expects the MM ID to be the public IP address of the router in front of ISA but I dont know how to resolve it.

Im using DH Group1 and DES only for testing porpouse only. Later, I will modify this, thanks for show me this.



justmee -> RE: ISA & Third party VPN site to site Over Ipsec PROBLEM (4.Jun.2008 4:35:55 PM)

quote:

Yes, I also see that the 3com router expects the MM ID to be the public IP address of the router in front of ISA but I dont know how to resolve it.

quote:

Yes, I configured the main mode id manually.

So if the 3com router allows/wants you to do this try with ISA's IP address. ISA uses its own IP address as MM ID (MM ID Type 1, meaning IP address).
You need NAT-T because ISA is behind a NAT device.



Nicomaco -> RE: ISA & Third party VPN site to site Over Ipsec PROBLEM (6.Jun.2008 3:09:36 AM)

I think that its necesary to enable Nat-T on Main office `s router. This is correct? The router is a "Micronet SP891 Dual Wan Security Gateway". It dont have the option to enable Nat-t, only the "IPSEC passthrough" option, but I enabled it, and the problem continues.

The 3com router is waiting for the IP 200.x.x.x on the payload but it cames with the ISA external interface(192.168.0.4). The branch router is configured with the public IP of the main router. Remember the 3Com router on the from the branch office:

Jun 3 15:03:46 localhost kernel: IKE: IKE -- MainMode -- initiator sent out message3 to 200.x.x.x, port 500->500.
Jun 3 15:03:46 localhost kernel: IKE: IKE -- MainMode -- initiator received response message3 from 200.x.x.x, port 500->500.
Jun 3 15:03:46 localhost kernel: IKE: IKE -- RemoteGateway ID in payload: IPV4_ADDR--192.168.0.4
Jun 3 15:03:46 localhost kernel: IKE: IKE --INVALID_ID_INFORMATION (0x12) -- peer
 200.x.x.x
Jun 3 15:03:46 localhost kernel: IKE: IKE --Sending Notification INVALID_ID_INFORMATION (0x12) to peer 200.x.x.x


Any Idea??

thanks...



justmee -> RE: ISA & Third party VPN site to site Over Ipsec PROBLEM (6.Jun.2008 7:43:33 AM)

NAT-T is an RFC based approach for dealing with NAT devices when using IPsec ESP.
NAT-T is only enabled on the VPN endpoints, in your case ISA and 3com.
IPsec ESP has problems passing through NAT devices.
Using NAT-T, ESP packets are encapsulated in UDP packets, which the NAT device can translate.

IPsec pasthrough makes the NAT device aware of ESP traffic, so it can translate it properly.
IPsec pasthrough appeared because NAT-T did not exist at that moment.

IPsec pasthrough "fixes" the NAT device.

NAT-T "fixes" the VPN endpoints, making them capable of detecting the present and location of NAT device(s) between them (during IKE negotiations).

So in theory NAT-T and IPsec passtrough are different things that do not overlap.
However, on some NAT devices you need to enable IPsec passthrough even when the IPsec peers are NAT-T capable in order to successfully connect.

The error you receive is from the third exchange of Main Mode.
You may enable NAT-T on the 3com router and still receive this error.
I know that your setup works with pre-shared keys when both VPN gateways are ISA 2006 for example.
I also know that it might not work with pre-shared keys when one end is a third-party VPN gateway.

There is a little hint here: in the third IKE MM exchange both peers pass their IDs, which in this case with pre-shared keys, are assumed to be the IP addresses of the initiator and responder, because this may be the only way to associate a pre-shared key with a VPN peer when using IKE MM.
But since ISA is behind the NAT device, it uses a private IP address, and the 3com routers assumes that ISA uses the public IP address of the NAT device.
When ISA adds its own private IP address as its MM ID, the 3com router will say oh no!

So in your case, if the 3com is NAT-T aware, in case of MM with pre-shared keys, it should accept the ID sent by ISA in order to work (basically anybody behind the NAT device can connect using this pre-shared key, there is no specific association between an IP address and a pre-shared key anymore).
Some VPN gateways do not accept this, and they require to use Aggressive Mode instead of Main Mode.
Some VPN gateways allow you to manually configure the MM ID. If the 3com allows you to do that, then you can specify ISA's IP address.
If I remember correctly, if ISA is a domain member, when is behind a NAT device, it may use its FQDN as MM ID.

Another option you may have, assuming that both peers are NAT-T aware, is to use certificates for IKE authentication (more secure) if the 3com router supports this authentication method.

If you can post your Oakley.log from ISA here, we can see if the 3com router is NAT-T aware (if NAT-T is enabled on it).



Nicomaco -> RE: ISA & Third party VPN site to site Over Ipsec PROBLEM (6.Jun.2008 11:57:55 AM)

quote:

ORIGINAL: justmee

The error you receive is from the third exchange of Main Mode.
You may enable NAT-T on the 3com router and still receive this error.


I cannot enable NAT-T on the 3com router (branch office) because it hasnt got that option.

quote:


There is a little hint here: in the third IKE MM exchange both peers pass their IDs, which in this case with pre-shared keys, are assumed to be the IP addresses of the initiator and responder, because this may be the only way to associate a pre-shared key with a VPN peer when using IKE MM.
But since ISA is behind the NAT device, it uses a private IP address, and the 3com routers assumes that ISA uses the public IP address of the NAT device.
When ISA adds its own private IP address as its MM ID, the 3com router will say oh no!


Exactly.. this is what happens... :-(

quote:


So in your case, if the 3com is NAT-T aware, in case of MM with pre-shared keys, it should accept the ID sent by ISA in order to work (basically anybody behind the NAT device can connect using this pre-shared key, there is no specific association between an IP address and a pre-shared key anymore).
Some VPN gateways do not accept this, and they require to use Aggressive Mode instead of Main Mode.

I will try enabling aggressive mode....

quote:


Another option you may have, assuming that both peers are NAT-T aware, is to use certificates for IKE authentication (more secure) if the 3com router supports this authentication method.

The 3com hasnt got the option of use certificates...

quote:


If you can post your Oakley.log from ISA here, we can see if the 3com router is NAT-T aware (if NAT-T is enabled on it).


I will try enabling agressive mode, an see the oakley.log....
Thanks for your extensive answer and sorry for my poor english.[&:]
I will tell you tomorrow....



justmee -> RE: ISA & Third party VPN site to site Over Ipsec PROBLEM (6.Jun.2008 12:01:40 PM)

Don't bother with Aggressive Mode as it is not supported on ISA.
No worries about your english.[:)]
I can easily understand what you are saying.
I'm not a native english speaker either...



Nicomaco -> RE: ISA & Third party VPN site to site Over Ipsec PROBLEM (6.Jun.2008 12:27:51 PM)

Hi.
Agressive mode is not supported by ISA?
In dont know what to do next.....
I must change the branch office router (3com)to anable NAT-T or the main office router(Micronet) to enable NAT -T on that router??
The last option is that... change the router... but I dont want to do this if its not the only way....

thanks justmee



justmee -> RE: ISA & Third party VPN site to site Over Ipsec PROBLEM (6.Jun.2008 2:00:04 PM)

Nope, aggressive mode is not supported on ISA.
NAT-T must be enabled on ISA and 3com.
On Micronet you should enable IPsec passthrough.

In theory this might work without NAT-T assuming that the Micronet router's IPsec passthrough functions.

But your problem is how to tell the 3com router to accept the Main Mode ID proposed by ISA (IP address 192.168.0.4) when using pre-shared keys.
If you cannot "fix" this on the 3com router, I do not see what else you can do with the current config.

Replacing the 3com router might solve your problem, assuming that the new device you will buy has not the same problem.
But didn't you say that the 3com router allows you to specify the MM ID ?

You should replace the Micronet router if only breaks your VPN connection. Right now its only fault is that it is in front of ISA and is doing NAT.
By the way, what's the purpose of the Micronet router in front of ISA ?
Do you really need it there ?
Getting rid of it and giving to ISA the public IP address might solve your problem.



Nicomaco -> RE: ISA & Third party VPN site to site Over Ipsec PROBLEM (6.Jun.2008 5:25:00 PM)

quote:

ORIGINAL: justmee

On Micronet you should enable IPsec passthrough.

Yes, ipsec passthrough is enabled on the Micronet.

quote:


But your problem is how to tell the 3com router to accept the Main Mode ID proposed by ISA (IP address 192.168.0.4) when using pre-shared keys.
If you cannot "fix" this on the 3com router, I do not see what else you can do with the current config.

Yes, I cannot fix this, because the router hasnt got this option...

quote:


Replacing the 3com router might solve your problem, assuming that the new device you will buy has not the same problem.
But didn't you say that the 3com router allows you to specify the MM ID ?

I can only setup the basic information for the tunnel connection as show in this picture:
[image]http://www.euzkalnik.com.ar/isa2.jpg[/image]


quote:


You should replace the Micronet router if only breaks your VPN connection. Right now its only fault is that it is in front of ISA and is doing NAT.
By the way, what's the purpose of the Micronet router in front of ISA ?
Do you really need it there ?
Getting rid of it and giving to ISA the public IP address might solve your problem.

The Micronet(main office router) is a dual wan loadbalancing gateway. It does load balancing with 2 wan connections and provides backup access to internet.
Correct me if Im wrong, but, until now, I have two alternatives:
1) Put out the main office router.
2) Change the 3com router (branch office) to another.
Theres another option?

Reviewing what we talk, this is the 2 alternatives.....

thanks alot justmee, I apreciate you goodwill.
Rafael



justmee -> RE: ISA & Third party VPN site to site Over Ipsec PROBLEM (7.Jun.2008 3:34:18 AM)

What happens when you put on the 3com router in the Remote IPsec Server ID field 192.168.0.4 ?
If I'm not wrong (I'm not familiar with 3coms) this may correspond to the needed MM ID.
And you should check the PFS field too. You've enabled on ISA (just in case you get to IKE QM negoatiations).



Nicomaco -> RE: ISA & Third party VPN site to site Over Ipsec PROBLEM (10.Jun.2008 12:28:46 AM)

Hi justmee.
Thanks for all the time you used to answer me.

quote:

ORIGINAL: justmee

What happens when you put on the 3com router in the Remote IPsec Server ID field 192.168.0.4 ?
If I'm not wrong (I'm not familiar with 3coms) this may correspond to the needed MM ID.

The same problem....
quote:


And you should check the PFS field too. You've enabled on ISA (just in case you get to IKE QM negoatiations).


Yes, I enabled it on isa... but nothing....
I dont know if I must manually enable Nat-T on ISA server.. Is this correct??
---x---
I change the branch office `s router to a linksys rv042 that support nat-t, but the problem persist.....
here de log from de linksys:
Jun 9 19:54:05 2008     VPN Log    Initiating Main Mode 
Jun 9 19:54:05 2008     VPN Log    [Tunnel Negotiation Info] >>> Initiator Send Main Mode 1st packet 
Jun 9 19:54:05 2008     VPN Log    Received Vendor ID payload Type = [MS NT5 ISAKMPOAKLEY 00000004] 
Jun 9 19:54:05 2008     VPN Log    Ignoring Vendor ID payload Type = [FRAGMENTATION] 
Jun 9 19:54:05 2008     VPN Log    Received Vendor ID payload Type = [draft-ietf-ipsec-nat-t-ike-02_n] 
Jun 9 19:54:05 2008     VPN Log    [Tunnel Negotiation Info] <<< Initiator Received Main Mode 2nd packet 
Jun 9 19:54:05 2008     VPN Log    [Tunnel Negotiation Info] >>> Initiator send Main Mode 3rd packet 
Jun 9 19:54:05 2008     VPN Log    [Tunnel Negotiation Info] <<< Initiator Received Main Mode 4th packet 
Jun 9 19:54:05 2008     VPN Log    [Tunnel Negotiation Info] >>> Initiator Send Main Mode 5th packet 
Jun 9 19:54:05 2008     VPN Log    [Tunnel Negotiation Info] >>> Initiator Receive Main Mode 6th packet 
Jun 9 19:54:05 2008     VPN Log    Main mode peer ID is ID_IPV4_ADDR: '192.168.0.4' 
Jun 9 19:54:05 2008     VPN Log    We require peer to have ID '200.x.x.x', but peer declares '192.168.0.4' 
Jun 9 19:54:06 2008     VPN Log    [Tunnel Negotiation Info] >>> Initiator Receive Main Mode 6th packet 
Jun 9 19:54:06 2008     VPN Log    Main mode peer ID is ID_IPV4_ADDR: '192.168.0.4' 
Jun 9 19:54:06 2008     VPN Log    We require peer to have ID '200.x.x.x', but peer declares '192.168.0.4' 
Jun 9 19:54:08 2008     VPN Log    [Tunnel Negotiation Info] >>> Initiator Receive Main Mode 6th packet 
Jun 9 19:54:08 2008     VPN Log    Main mode peer ID is ID_IPV4_ADDR: '192.168.0.4' 
Jun 9 19:54:08 2008     VPN Log    We require peer to have ID '200.x.x.x', but peer declares '192.168.0.4' 
Jun 9 19:54:12 2008     VPN Log    [Tunnel Negotiation Info] >>> Initiator Receive Main Mode 6th packet 
Jun 9 19:54:12 2008     VPN Log    Main mode peer ID is ID_IPV4_ADDR: '192.168.0.4' 
Jun 9 19:54:12 2008     VPN Log    We require peer to have ID '200.x.x.x', but peer declares '192.168.0.4' 
Jun 9 19:54:16 2008     VPN Log    Informational Exchange is for an unknown (expired?) SA 
Jun 9 19:54:20 2008     VPN Log    [Tunnel Negotiation Info] >>> Initiator Receive Main Mode 6th packet 
Jun 9 19:54:20 2008     VPN Log    Main mode peer ID is ID_IPV4_ADDR: '192.168.0.4' 
Jun 9 19:54:20 2008     VPN Log    We require peer to have ID '200.x.x.x', but peer declares '192.168.0.4' 
Jun 9 19:54:36 2008     VPN Log    [Tunnel Negotiation Info] >>> Initiator Receive Main Mode 6th packet 
Jun 9 19:54:36 2008     VPN Log    Main mode peer ID is ID_IPV4_ADDR: '192.168.0.4' 
Jun 9 19:54:36 2008     VPN Log    We require peer to have ID '200.x.x.x', but peer declares '192.168.0.4' 


-----------------------------------------------------

As we can see, the problem is exactly the same. Im looking on internet, and theres a lot of people having the same trouble, but no information to figure it out.
I dont want to extract the Dual Wan with Load balancing Micronet router, but It seeems that i have no choise.....



justmee -> RE: ISA & Third party VPN site to site Over Ipsec PROBLEM (10.Jun.2008 9:39:45 AM)

Hi Rafael,
At a first glance it looks like the Remote IPsec Server ID field was used to specify the MM ID, but...
NAT-T is enabled on ISA so you do not have to enable it.
As you can see ISA has sent the NAT-T Vendor ID to the Linksys:
quote:

Jun 9 19:54:05 2008     VPN Log    Received Vendor ID payload Type = [draft-ietf-ipsec-nat-t-ike-02_n]

ISA's NAT-T implementation is based on the draft version.

It looks that it's hard coded to expect the pre-shared ley to be associated with the public IP on these cheap devices even when one peer is behind a NAT device. Maybe this is not a bad thing from a security perspective, assuming that there is a security perspective with pre-shared keys.
With IKE Main Mode, with pre-shared keys auth, the peer ID is sent within the third round of IKE messages(encrypted messages). So the ID is unknown till then.
The pre-shared key is associated with the remote gateway IP address, the "authentication" mechanism expects the MM ID to be the public IP address.

But when the remote peer is behind a NAT device, with MM, and this NAT device is detected (through NAT-T), you cannot really associate an IP address with that pre-shared key -authenticate based on IP addresses- (negotiations "start" from the public IP address of the NAT device, thus any device behind the NAT device can "start" the connection).

With IKE Aggressive Mode, the IDs are passed in clear at the beginning, so the peers know which pre-shared key to select.
Due to some security issues associated with Aggressive Mode, Microsoft does not uses it.

The most simple solution to your problem (to keep your current layout), will be to replace the 3com router with a VPN gateway supporting certificates authentication (pre-shared keys are a weak authentication method) and NAT-T based on the draft version.

A temporary solution can be to remove the NAT device(dual wan router).
I would not try to terminate the site-to-site VPN on the Micronet router (if this device support this).

If you have a spare PC, you can try to replace the 3com router with one of the open source solutions, take a look at IPCop (you don't need to buy anything and then discover that is still not working). IMHO, assuming this will work work (I'm not familiar with it), it looks like a better solution than Linksys.
With pfSense they mention that NAT-T is not currently supported.
As said before, in theory it might work without NAT-T assuming that the IPsec passthough function on the Micronet router is working, so it can properly translate the ESP packets.
Regards!



Nicomaco -> RE: ISA & Third party VPN site to site Over Ipsec PROBLEM (11.Jun.2008 12:08:14 AM)

Hi Justmee, how are you??

I put away the router (Micronet) between the ISA and the linksys.
Now the VPN site to site works fine fine.

I have actually a couple of problems with the access to the internal lan of the main office.
The pcs on the branch can access only http to mains lan, but other traffic cannot.

ping, netshare, rdp, etc..

The rules are:
(for testing purpose only)

LAN-->VPNsite allow all  outbound traffic   --> all users
VPNsite-->LAN allow all  outbound traffic --> all users
ISA-->VPNsite allow all outbound traffic --> all users


From mains office net(LAN), I cannot access the the branch office net (VPNsite)
using any protocol.

From branch `s net, i can ping and rdp isa server, because i edit the firewall system policy. (I create the rule VPNsite -->ISA allow all outbound traffic --> all users, but cannot access Isa server, only when I edit the isa firewall system policy I were able connect using rdp to ISA)


A lot of issues and problems here.....

Thanks.



justmee -> RE: ISA & Third party VPN site to site Over Ipsec PROBLEM (11.Jun.2008 6:58:54 AM)

I suppose you have a route relationship between the remote VPN site and the Internal Network on ISA.
You can run ISA BPA to see if it finds something.
Additionally you can check ISA's logs.
You can check if you don't have some MTU issues.
Testing from ISA itself is tricky with IPsec tunnel mode:
http://www.isaserver.org/tutorials/Troubleshooting-IPSec-Tunnel-Mode-Scenarios.html
You should first test from a host behind ISA to a host behind Linksys and vice-versa.
You can use the mmc and the IPsec monitor Snap-in on ISA to see the current MM and QM SAs, and to find more details about the established IPsec connection.
Additionally you can start some Wireshark traces along the path, as you may figure it out where the black hole is.



Nicomaco -> RE: ISA & Third party VPN site to site Over Ipsec PROBLEM (12.Jun.2008 12:41:23 AM)

I found the problem.

The IP machines that use to test the site to site vpn connection, have other gateway than internal ISA IPs, so the echo reply couldn t reach the pc of the other lan, trought the tunnel connection. And this is why http traffic can flow whitout any problem, but no ping, rdp, etc, etc etc.

this post is now close.!



Page: [1]