12 Replies Latest reply on Jul 12, 2017 7:11 AM by mick

    VPN Connection Issue

    joe361 New Member

      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

        • Re: VPN Connection Issue
          jayh Hall_of_Fame

          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.

            • Re: VPN Connection Issue
              joe361 New Member

              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

                • Re: VPN Connection Issue
                  jayh Hall_of_Fame

                  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.

                    • Re: VPN Connection Issue
                      joe361 New Member

                      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
                          mick Visitor

                          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

                          • Re: VPN Connection Issue
                            jayh Hall_of_Fame

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

                              • Re: VPN Connection Issue
                                joe361 New Member

                                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
                                    mick Visitor

                                    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

                                      • Re: VPN Connection Issue
                                        joe361 New Member

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

                                         

                                        untitled.JPG

                                          • Re: VPN Connection Issue
                                            mick Visitor

                                            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

                                              • Re: VPN Connection Issue
                                                joe361 New Member

                                                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
                                                    mick Visitor

                                                    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