Troubleshooting Linksys LRT214 VPN Router Issues

Troubleshooting a Linksys LRT214:

I recently had to install a Linksys LRT214 Router, the install itself went well but there were a few issues along the way.   One thing I like about the LRT214 VPN Router is that it offers a full client to site VPN Tunnel using IPSEC.  The setup itself was extremely easy and only took a few minutes, the issues arose when the clients started trying to connect to the system as no error was given.

Issue #1:

The first issue was that I was not able to use the existing adapter in the shrew.net vpn client that Linksys recommends per their documentation.  Apparently, in some cases using the existing local adapter can cause the vpn tunnel to loop and therefore fail in establishing a connection.  The recommended setting is to use a virtual adapter and a random address that is outside the range of the network you are connecting too.

Issue #2:

The second issue was far more frustrating.  The tunnel would immediately enable without error but the client would not be able to reach any network resources except the switch itself…  In some cases some network resources would be available but not all.  The first telltale sign was in the logs:

Feb 7 20:07:27 2017    VPN Log    (grpips0)[130] 192.168.2.0/24=== …1.2.3.4===? #248: [Tunnel Established] ISAKMP SA established
Feb 7 20:07:54 2017    VPN Log    (grpips0)[130] 192.168.2.0/24=== …1.2.3.4===?: [Tunnel Disconnected] instance with peer 1.2.3.4 {isakmp=#0/ipsec=#0}

The tunnel is established and the ISAKMP SA is established, but nothing moves… Then the strange thing, one system was able to connect:

Feb 8 06:39:19 2017    VPN Log    (grpips0)[133] 192.168.2.0/24=== …4.3.2.1===? #251: [Tunnel Established] ISAKMP SA established
Feb 8 06:39:23 2017    VPN Log    (grpips0)[133] 192.168.2.0/24=== …4.3.2.1===198.18.0.0/32 #252: [Tunnel Established] IPsec SA established {ESP=>0x06c8fd59 < 0xe0bb64ad NATOA=0.0.0.0}

So why is one connection successfully completing the IPsec SA and the other is not?  The simple answer is its a result of the IP settings on the client network. For example, if the remote network is 192.168.2.0 then the client must be on a separate network, they cannot be on the same subnet.  You can liken it to trying to send a letter from yourself to yourself, the post office will just leave it in your mailbox and it will never go anywhere.

Solution:  Break apart the subnets, regardless of the virtual adapter settings.

Client Network: 192.168.3.0  (Subnet is 192.168.3)

Server Network: 192:168.2.0 (Subnet is 192.168.2)

IPsec will work because when it tries to push the resources for 192.168.2.0 now it won’t conflict with the clients internal network.

Leave a Reply

Your email address will not be published.