Remote Office Router: 2927 (4.5.1)
Main Office Router: 2952 (3.9.8.

We have a remote office with Lan-Lan vpn connection to main office using IPsec Tunnel. Connection to the main office is via WAN2 Alias 3

Remote office Network 192.168.4.1   -- Connecting to Main office LAN 192.168.14.1

This works fine. 

We also have some remote users who need to connect the main office via VPN to the Main office network 19.168.1.1.

They connect a different IP address on WAN1 using IPsec TunnelBefore we implemented the Lan-to-Lan vpn remotes users could connect to the VPN from the Remote office without issue.After the LAN-to-LAN vpn was implemented, remote users can no longer connect from the Remote office. Eventually the IP address of the remote office is added to the Banned list on the Main Office router.

Since the IP address of the Remote office is the same for both the remote user VPN and the LAN-to-LAN VPN we can only assume the remote users are not allowed to connect as the Router thinks they are the LAN-to-LAN VPN and connecting with the wrong credentials.

HOWEVER. If we disable the LAN-to-LAN connection on the main office router.
Then connect the Remote users they can connect ok.
We then Enable the LAN-to-LAN connection with the remote users still connected and the Remote office also connects without issue.

Both VPN connect and work as expected.

Disconnect the Remote user then try to reconnect with the LAN-to-LAN still active and the remote user can no longer connect.

The LAN-to-LAN VPN connects to a different IP and WAN Port on the Main Office router than the Remote User VPN and to different LANs on the Main office router.Is this a feature or a bug. Bear in mind that both VPNs can work simultaneously but only if the Remote user VPN connect first before the LAN-to-LAN vpn is activated.

Hi pcjazzit ,

If I am understanding your post correctly, as it is a little tricky to follow...:

I would guess you're having routing issues, brought on by adding too many routes to the same place(s).

Your devices will not be allowed to connect to a route that clashes with a route they already have in their local routing table. Hence why the 'Remote Users' can't connect into the 'Main Office', because a check will be done at the connection stage that will check to see if the device's subnet is already in use at the 'Main Office' which it will be if you have the LAN-to-LAN active already. So the 'Main Office' router won't allow them to connect as it won't be able to send traffic back to them directly if it now has two subnets connected to it that are the same; hence why it fails the connection.

If the remote users are at the remote site, why do they need to VPN in to the 'Main Office' again? Why don't you just route them through the already established LAN-to-LAN connection?


 

HodgesanDY many thanks for your reply.
I appreciate the description may be a little tricky to follow. I will try to make it clearer.

Main office: 
WAN 1 – External IP     xxx.xxx.xxx.100   <-- used for Remote User VPN
WAN 2 – External IP     alias1 xxx.xxx.xxx.101    
alias1 xxx.xxx.xxx.102
alias1 xxx.xxx.xxx.103 <-- used for LAN-to-LAN VPN
alias1 xxx.xxx.xxx.104

LAN 1 – 192.168.1.1/24    used for Remote users
LAN 3 - 192.168.140.1/24    used for the LAN-to-LAN VPN

Serviced Office: Primary Router (Not A vigor, and not controlled by us) 
WAN External IP: xxx.xxx.xxx.200 
LAN IP Subnet 192.168.10.1/24
This has a wifi for users and from here they can access to internet. Remote users will VPN onto the Main Office as they would from any location. 

“Remote Office Router”
Inside the Primary Router and NAT’d 
WAN 1 - DHCP from the Primary Router 192.168.20.1/24. (This is a different subnet that the Remote users use.)
LAN 1 – 192.168.145.1/24

The LAN-to-LAN VPN connects 192.168.145.1 on the “Remote Office Router” to 192.168.140.1 (LAN 3) on the Main Office Router.

Remote Users VPN from wherever they are to the 192.168.1.1 (LAN 1) on the Main Router.

Both the LAN-to-LAN Vpn and the remote users will have the same external IP xxx.xxx.xxx.200 even though they are on different subnets.

In response to your observation. The LAN-to-LAN vpn uses a different subnet to the Remote users.

The remote users will not have access to the Remote Office 192.168.140.1 network as this is for a specific traffic not “user” traffic. In any case this is a large service office and they may not actually be in the same location as the “Remote Office Router”.

Both VPN connections can work simultaneously in the following conditions;
1 – Disable the LAN-to-LAN on the Main Office Router
2 – Connect the Remote user VPN
3 – Enable the LAN-TO-LAN vpn.
In this scenario both vpn are connected and operating as expected with the Remote User and LAN-to-LAN traffic over the correct subnets.

However, as soon as the Remote user disconnects the VPN they cannot reconnect. The Main Office router will eventually block the external IP xxx.xxx.xxx.200 even though the Lan-to-LN vpn will continues to be connected.

The problem is not a subnet. The LAN-to-LAN vpn takes precedent over the inbound IP address of the connecting VPN and the router cannot distinguish between LAN-to-LAN or Remote Users. 





 

Hi  pcjazzit ,

In your LAN-to-LAN connection profile, from the 'Remote Office' to the 'Main Office', are you routing all traffic from the ROffice through the MOffice? I.e. if you do a "whatismyipaddress"  check from the remote user's device while it is connected to the remote network - that is also connected to the MOffice via L2L (regardless of subnet) - do you get the MOffice public IP(s) address(es)?

If this is the case, then the remote users are attempting to make a VPN connection from a WAN route back into the same WAN they're routed through. Hence why, if you disconnect the L2L and try to connect them, they are now establishing a connection from a different public WAN address and so are allowed to connect to the MOffice. Once this scenario is connected, the L2L connection between routers would still be acceptable, as the remote user device isn't factored into the new L2L connection between routers, their (the remote user's device) route has already been established on their device, so that path/route will hold.

Just a theory/possibility...