cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
joe361
New Contributor

VPN Connection Issue

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?

untitled.JPG

Labels (1)
0 Kudos
13 Replies
jayh
Honored Contributor
Honored Contributor

Re: VPN Connection Issue

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
New Contributor

Re: VPN Connection Issue

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?

vpn.JPG

jayh
Honored Contributor
Honored Contributor

Re: VPN Connection Issue

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
New Contributor

Re: VPN Connection Issue

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

vpn.JPG

VPN2.JPG

VPN3.JPG

Re: VPN Connection Issue

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
Honored Contributor
Honored Contributor

Re: VPN Connection Issue

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
New Contributor

Re: VPN Connection Issue

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

Screen from the NetVanta

pic1.JPG

Client

pic2.JPGpic3.JPG

Re: VPN Connection Issue

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
New Contributor

Re: VPN Connection Issue

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

untitled.JPG

Re: VPN Connection Issue

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
New Contributor

Re: VPN Connection Issue

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

vpn2.JPG

Re: VPN Connection Issue

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

Re: VPN Connection Issue

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