VPN Connection Issue

[joe361]

I'm attempting to use Shrew VPN(2.2.2) client to connect to a NetVanta 3120 but it hangs on "bringing up tunnel."  It looks like I'm receiving "CRYPTO_IKE.MODE_CONFIG ModeCfgProcess: ModeCfgAllocateResources Failed"  Any ideas?

[jayh]

This looks like a remote access VPN, where you assign a private address from a pool to the client.

The address pool you are using is part of a subnet bound to an interface.

Try configuring a new subnet for the remote access clients not bound to an interface.

[joe361]

Not clear on what you want me to do.  Doesn't the VPN client need to be on the same subnet as the internal network?

[jayh]

joe361 wrote:

Not clear on what you want me to do. Doesn't the VPN client need to be on the same subnet as the internal network?

No. It should be on a separate subnet than your connected interface. Otherwise there's an IP conflict between the tunnel source and tunnel destination. So use something like 10.100.0.1 through 10.100.0.254 as an example assuming it isn't used elsewhere. Keep your DNS and WINS servers in the configuration as they are. Clients will reach them over the VPN.

[joe361]

Used your IP range now I can connect thanks but I'm unable to ping or RDP to an internal server.

[mick]

Hi joe361,

The last screenshot from your router shows that the IPSec tunnel is not yet established.  So something is causing phase 2 of the VPN to fail.  What does the log on either side of the tunnel show?

--

Regards,

Mick

[jayh]

IKE is up but IPSec is down in your screenshot. Check your IPSec configuration, PSK, etc. Are the local and remote protected networks correct?

[joe361]

I was using the instructions here, https://www.shrew.net/support/Howto_Adtran

Screen from the NetVanta

Client

[mick]

Hi Joe361,

If you followed the configuration instructions on the shrew.net page the connection ought to succeed.  Connect to the router with SSH or Telnet and run a debug session while the Shrew client attempts to connect.  The debug command to run is: 'debug crypto ike'

Then search through the stream of debug messages to find confirmation of the following:

1. A message from CRYPTO_IKE.NEGOTIATION which will say the 'aggressive mode is complete'.

2. A message from CRYPTO_IKE, which will say the XAuthentication .has succeeded: CRYPTO_IKE.XAUTH EDCallBackFun: Xauth succeeded

3. A message from CRYPTO_IKE confirming the Quick Mode is starting:  CRYPTO_IKE.NEGOTIATION peer AA.BBB.CCC.DD: Received first message of quick mode (where AA.BBB.CCC.DD is the Internet IP address of the Shrew client PC).

4. A message from CRYPTO_IKE confirming the Quick Mode has completed:  CRYPTO_IKE.NEGOTIATION peer AA.BBB.CCC.DD: Quick mode completed

Until step 4 above is completed the IPSec tunnel is not yet up and no packets will flow.  To get the tunnel established you may need to ping the server from the client PC, or a routable device behind the Netvanta, once or twice.  If you never arrive at step 4, then you will need to retrace your steps for any typos or configuration errors.  If you do arrive at step 4 but still cannot access the server, then you should check the server configuration and logs to confirm if any packets arrive there from the client PC.

Please report back with your results if you get stuck.

--

Kind regards,

Mick

[joe361]

The debug command didn't work but this is what I got.

[mick]

Hi Joe361,

Thanks for this.  For the debug command to work in a terminal you need to enter the 'enable' command first to elevate your login from the Basic login mode, or you could use the GUI as you did in your original post.  Either way, the content would be easier to read if you could select/copy/paste into the forums, obfuscating any IP addresses you do not wish to publish.

From what you posted above the cause of the problem seems to be the same as your original post and jayh's suggestion applies.  The Netvanta's LAN subnet is the same like the one you have set up to be the virtual subnet for VPN clients.  The two have to be different, or routing will become exceedingly complex.  If you check your output in the terminal it says:

"IP Pool contains the IP that belongs to subnet to which one of the interfaces belongs"

This means you have configured Netvanta to allocate IP addresses to VPN clients from the same subnet that is already allocated to one of its own interfaces and this creates an address space clash.  For the avoidance of doubt:

Mobile-Client===========Router=======(INTERNET)=======Netvanta-----------LAN_SUBNET

192.168.1.8                RST.UVW.XY.Z                                         ABC.DEF.GH.IJK           10.10.10.0/24

Mobile-Client=====================(VPN TUNNEL)=======Netvanta----------LAN_SERVER

(Virtual IP)                                                                                  ABC.DEF.GH.IJK

172.16.100.1                                                                                                              10.10.10.2/32

In the above example the Shrew Client's LAN address is 192.168.1.8 and this belongs to a different subnet space than the LAN subnet of 10.10.10.0/24.  RST.UVW.XY.Z and ABC.DEF.GH.IJK respectively are the public IP addresses of the router the Shrew Client is connected to and Netvanta's.  When you are setting a virtual IP address range for remote VPN clients, this will also have to be different to the Netvanta's LAN subnet, in the above example I set it within a range of 172.16.100.0/24.  This will ensure packets are routed out of the correct interface (physical port, or VPN tunnel) without any clashes in the subnets' address space.

As jayh suggested, use a different subnet for the VPN client range to what is used for the LAN behind the Netvanta and then the connection will be able to progress to the next stage.

--

Kind regards,

Mick

[joe361]

I made the following change to the IP address range and I can now connect but I don't have connectivity.  Can't ping internal hosts.

[mick]

Hi joe361, how do you know if the IPSec tunnel has been established?  In a debug Crypto/IKE session at the router do you see an entry showing:

CRYPTO_IKE.NEGOTIATION peer AA.BBB.CCC.DD: Quick mode completed

where AA.BBB.CCC.DD is the public IP address of the remote client?  If yes, then the tunnel is up.  If no, the tunnel is not yet established and further troubleshooting is required.  Having completed the Phase 1 IKE negotiation does not necessarily mean the Phase 2, IPSec connection is also established.  If IPSec is yet to be completed, the Shrew log and router debug output should point to the causes.  Let us know what they show and we'll take it from there.

However, if the IPSec tunnel is now established then what do the server firewall logs show?  Do packets arrive there from remote client's IP address 10.0.1.240?  If the server does not respond to ICMP packets, does it respond to HTTP if it is a web server, or whatever protocol for the services it provides?

--

Kind regards,

Mick

[suarezisok]

Hey, you should try using http://bestvpnrating.com/  to make it's possible to be safe on web.