I'm in need of some clarification on your issue. Do you want to stretch the VLANs from remote sites back to HQ so you have layer 2 connectivity between the sites? Do you want layer 3 connectivity between the locations from the additional networks present on the remote site VLANs (ping from that VLAN to HQ)?

I'm in need of some clarification on your issue. Do you want to stretch the VLANs from remote sites back to HQ so you have layer 2 connectivity between the sites? Do you want layer 3 connectivity between the locations from the additional networks present on the remote site VLANs (ping from that VLAN to HQ)?

The vlans at each site does not have to be in the same network as long as they can sent back there data to HQ Servers.

As long as the Server can see and ping it will be good.

I hope that answers your question.

I'm in need of some clarification on your issue. Do you want to stretch the VLANs from remote sites back to HQ so you have layer 2 connectivity between the sites? Do you want layer 3 connectivity between the locations from the additional networks present on the remote site VLANs (ping from that VLAN to HQ)?

The vlans at each site does not have to be in the same network as long as they can sent back there data to HQ Servers.

As long as the Server can see and ping it will be good.

I hope that answers your question.

Yes it does, so we'll target layer 3 connectivity and we won't strectch the VLANs over the WAN links. Because you have working L2TP/IPSec connections now your problem is most likely just a routing problem. With L2TP/IPSec you shouldn't need any NAT exclusion rules because it creates an interface and is capable of routing packets naturally. If you were doing a strict IPSec transport mode tunnel you would likely need to use NAT exclusion rules to site to site traffic is NAT'd out to the Internet, this is called a policy based VPN.

You can keep your existing L2TP implementation, with PPP you have the ability to add routes on the server side (HQ, likely). This is done in the /ppp secret menu. You'd use the "route" attribute. This can be leveraged to automatically activate and deactivate a route for each remote-site by having a user for each site and placing a route for each VLAN at the site in the "routes" attribute.

At your client sites, you'll need to use static routes if you don't set the default route to the HQ. You'll need a static route for each network at all remote site networks other than itself and the HQ networks. An alternative for IPv4 would be to specify all RFC1918 addressing to go out over the tunnels. This would keep the benefit of Internet traffic going out locally while tunneling all traffic back to HQ that should be "local."

Dynamic Routing
If you don't want to manage all the routing information, you can use BGP or static OSPF neighbors over L2TP. If you don't feel comfortable with that you can switch to another tunneling technology like GRE that supports multicast which allows a protocol like OSPF or RIP to work as expected. That said, GRE requires static IPs at each remote site and HQ. You can use dynamic addressing with GRE but it requires scripting or manual adjustments to handle Internet IP changes. Like L2TP the GRE tunnels can be wrapped with a transport mode IPSec connection for security.

An example with the networks of 192.168.101.0/24 with a gateway of 192.168.255.1/30 and 192.168.201.0/24 with a gateway of 192.168.255.5/30.

Code: Select all

ppp secret set 0 routes="192.168.101.0/24 192.168.255.1 1,192.168.201.0/24 192.168.255.5 1"

https://wiki.mikrotik.com/wiki/Manual:PPP_AAA

^^ Search for "routes"

This needs to be performed on the device acting as the L2TP server. It will only inject routes on the L2TP server so the client needs to either accept a default route back to the server or have local static routes.

Post a /ip route print from the hq and one of the branches. Maybe a little drawing showing the networks involved too.

Post a /ip route print from the hq and one of the branches. Maybe a little drawing showing the networks involved too.

HQ Route list



The one that say 10.3.0.0 and 10.10.10.0 are from the Vlans test site.


Client route list




Network layout simple

/ppp export hide-sensitive

Post a /ip route print from the hq and one of the branches. Maybe a little drawing showing the networks involved too.

HQ Route list



The one that say 10.3.0.0 and 10.10.10.0 are from the Vlans test site.


Client route list




Network layout simple

For the HQ side with PPP Secrets based routes you'll need a gateway that is test site's router IP that is reachable from HQ. This usually manifests itself as the IP assigned to the link connecting the routers, the L2TP connection in your case. If you're assigning this statically in the PPP Secret as well via remote-address then specify this as the gateway.

Please post the results of (terminal):

Code: Select all

/ppp export hide-sensitive

Post a /ip route print from the hq and one of the branches. Maybe a little drawing showing the networks involved too.

HQ Route list



The one that say 10.3.0.0 and 10.10.10.0 are from the Vlans test site.


Client route list




Network layout simple

For the HQ side with PPP Secrets based routes you'll need a gateway that is test site's router IP that is reachable from HQ. This usually manifests itself as the IP assigned to the link connecting the routers, the L2TP connection in your case. If you're assigning this statically in the PPP Secret as well via remote-address then specify this as the gateway.

Please post the results of (terminal):

Code: Select all

/ppp export hide-sensitive

add comment="Site1 VPN" local-address=192.168.1.1 name=user1 remote-address=\
192.168.2.1 service=l2tp
add comment=Site2 local-address=192.168.1.1 name=user2 remote-address=\
192.168.3.1 service=l2tp
add comment=Test local-address=192.168.1.1 name=user3 remote-address=\
192.168.88.1 routes="10.10.10.0/24 10.10.10.1 1, 10.3.0.0/24 10.3.0.1 1" \
service=l2tp

Post a /ip route print from the hq and one of the branches. Maybe a little drawing showing the networks involved too.

HQ Route list



The one that say 10.3.0.0 and 10.10.10.0 are from the Vlans test site.


Client route list




Network layout simple

For the HQ side with PPP Secrets based routes you'll need a gateway that is test site's router IP that is reachable from HQ. This usually manifests itself as the IP assigned to the link connecting the routers, the L2TP connection in your case. If you're assigning this statically in the PPP Secret as well via remote-address then specify this as the gateway.

Please post the results of (terminal):

Code: Select all

/ppp export hide-sensitive

add comment="Site1 VPN" local-address=192.168.1.1 name=user1 remote-address=\
192.168.2.1 service=l2tp
add comment=Site2 local-address=192.168.1.1 name=user2 remote-address=\
192.168.3.1 service=l2tp
add comment=Test local-address=192.168.1.1 name=user3 remote-address=\
192.168.88.1 routes="10.10.10.0/24 10.10.10.1 1, 10.3.0.0/24 10.3.0.1 1" \
service=l2tp

So, when using L2TP in the fashion you are (as a site to site VPN) when I do not need to present the same subnet in both sites (stretched) I typically make the local-address and remote-address part of unique non-overlapping ranges. This keeps things clean and won't require the use of Proxy ARP.

To do this, grab an unused private IP, say 10.255.255.0/24. Assign IPs from this /24 to each site. I also prefer to create a unique local-address for each client for this particular use case since everything else is statically defined. It helps in troubleshooting with traceroute and knowing 100% for sure the correct IP is chosen for routes.

So, hypothetically, if we use 10.255.255.0/24. Let's do:

Site1 local-address: 10.255.255.11
Site1 remote-address: 10.255.255.61
Site2 local-address: 10.255.255.12
Site2 remote-address: 10.255.255.62
Site3 (test) local-address: 10.255.255.13
Site3 (test) remote-address: 10.255.255.63

You would then adjust the routes section in PPP secrets to be "10.3.0.0/24 10.255.255.63 251,10.10.10.0/24 10.255.255.63 251"

I set a higher than normal distance here as a precaution to allow any future dynamic protocols to take precedence.

idlemind
Thank you for all your help. I appreciate.