MikroTik

Hi,

I have setup an EOIP tunnel over SSTP from site1 VLAN to site2.
I am trying to split traffic over WAN from site2 on MT2 router to go straight out ISP gateway
instead of LAN gateway over EOIP tunnel.. how would I do this..?

First, sending EoIP over SSTP is an overkill unless you need to transport multiple VLANs over the same L2 tunnel - if one VLAN is enough, you can use the BCP capability of SSTP which basically builds an L2 tunnel between the client and server, in parallel to the L3 one, and attaches it as a member port to a bridge indicated in the /ppp profile row used by that /interface sstp-client (on client side) and /ppp secret (on server side).

Second and more important, you're likely to regret multiple times in future the decision to tunnel L2 traffic via a VPN which uses TCP as transport, unless you want it only for management (which, on the other hand, doesn't justify use of L2). So do think about IPsec.

And last, please draw the topology and the two types of traffic you want to "split". It's not clear (at least to me) what you actually want. Normally, the default gateway of site 2 would remain the WAN one, and you would only set up dedicated routes via the VPN, but you seem to plan to interconnect the site LANs on L2? If so, and if you want LAN hosts at each site to use a different gateway, the easiest way for me would be to attach a DHCP server to each site's bridge, with non-overlapping pools and different gateway settings, and prevent DHCP requests from clients to be bridged between the sites by means of /interface bridge filter rules. So clients at each site would get addresses from the same subnet but from a local DHCP server.

Thanks for the reply.

Well, yes I was going access two vlans over the EOIP tunnel. Really for troubleshooting and testing purposes.
Maybe I do not need an EOIP over SSTP configuration..?

I need to login to the domain/AD from the remote office to HQ as if I were in the HQ office...
From what I have read; I thought would need an L2 transport over an L3 connection.
What should I be doing to extend HQ vlans to the remote office?

And lets say I only need to extend one vlan and not two.. then best choice?

Furthermore, when the remote office PC1 is connected to HQ vlan; I want the vlan traffic for
PC1 connected to vlans to stay on the vlan gateway (which it does by default) then... when
PC1 sends traffic outside of the vlan to the public WAN... I want to use a different gateway (ISP)
so that PC1 is not consuming bandwidth from HQ for surfing or doing traffic not related to vlans...
Rather, PC1 uses its own ISP provider bandwidth for non-related vlan traffic.

So... optimal solutions?

Well, yes I was going access two vlans over the EOIP tunnel. ...
Maybe I do not need an EOIP over SSTP configuration..?

If you use the single-bridge-for-all-vlans approach with vlan-filtering=yes on the bridge, you cannot attach the BCP L2 tunnel directly to that br-all-vlans, because this dynamic addition does not support vlan-filtering=yes (at least it didn't a year ago).

So you can either use the EoIP tunnel as you've planned, or you can save some overhead bytes (= link bandwidth and likely also some CPU) by using 802.1ad service-vlan tagging to transport a trunk of 802.1Q customer-vlans:
bcp tunnel <-> br-s-vlan(0x88a8) <-> (T)br-s-vlan.7(U) <-> br-all-vlans(0x8100)

The corresponding commands would look as follows (at both the SSTP server side and SSTP client side):
/interface bridge add name=br-s-vlan vlan-filtering=no ether-type=0x88a8
/interface vlan add name=br-s-vlan.7 interface=br-s-vlan use-service-tag=yes vlan-id=7
/interface bridge port add bridge-br-all-vlans interface=br-s-vlan.7
.....a generic command would be too complex, so in plain words: add the br-s-vlan.7 to the tagged list of all rows of /interface bridge vlan whose vlan-ids contain the VLANs you want to transport via the tunel...
/ppp profile add copy-from=default-encryption name=sstp-s-bridge bridge=br-s-vlan

On the SSTP server side only:
/ppp secret set <your-secret-name> profile=sstp-s-bridge

On the SSTP client side only
/interface sstp-client set <your-interface-name> profile=sstp-s-bridge

Furthermore, when the remote office PC1 is connected to HQ vlan; I want the vlan traffic for
PC1 connected to vlans to stay on the vlan gateway (which it does by default) then... when
PC1 sends traffic outside of the vlan to the public WAN... I want to use a different gateway (ISP)
so that PC1 is not consuming bandwidth from HQ for surfing or doing traffic not related to vlans...
Rather, PC1 uses its own ISP provider bandwidth for non-related vlan traffic.

Well, let's first differentiate between "gateway", "route", and the misleading shortcut "default gateway" which actually means "default route's gateway".

To talk to other devices inside its own IP subnet (which typically maps 1:1 to a VLAN ID but it is not a law of physics), a device needs no gateway as these are reachable directly on L2. So routes with one of own subnets as destination have the corresponding interface itself as a gateway. Such subnets are called "connected" ones.

To talk to devices outside connected subnets, the device needs to send the packets via a router device in one of the connected subnets (a gateway router), so the routes to these destinations indicate IP addresses of these routers as gateways. And one of the routes may be a default one (which is used if no other route matches more narrowly). And since many end devices, like the PCs, have no other routes configured, the shortcut became known as "default gateway" (because you only have to configure the gateway information, whereas the dst-address=0.0.0.0/0 part is implicit).

So... as long as you only need the PC to talk to other devices in the same VLAN/subnet where it is connected via the tunnel, and to the rest of the world via the WAN of the Mikrotik to which it is connected, what I wrote earlier is enough - the default gateway for that PC will be the own IP address, in the subnet where the PC is connected, of the Mikrotik where the PC is connected, and that's it (so the Mikrotik at each end of the tunnel must have its own IP in each of the two subnets which live in each of the two VLANs).

If you want that the PC at the BO end can access also some other, non-connected, subnets in the HQ network via the VLAN tunnel, the situation is more complex. If you add these routes to the BO Mikrotik itself, what should happen is that the PC sends the packet to the BO Mikrotik, the BO Mikrotik determines that the in-interface and out-interface of the packet are the same, so it sends an ICMP notification about a better gateway to the PC, which should accept it and send the packet to the HQ Mikrotik (and cache this for a while so it will send the subsequent packets via the HQ mikrotik straight away). So try this first, and if it doesn't help, come back, I'll write something regarding dynamic configuration of client's routing tables using DHCP.

Thanks for the reply.

So... as long as you only need the PC to talk to other devices in the same VLAN/subnet where it is connected via the tunnel, and to the rest of the world via the WAN of the Mikrotik to which it is connected, what I wrote earlier is enough - the default gateway for that PC will be the own IP address, in the subnet where the PC is connected, of the Mikrotik where the PC is connected, and that's it (so the Mikrotik at each end of the tunnel must have its own IP in each of the two subnets which live in each of the two VLANs).

So... PC1 on MT1 gets all its network information from DHCP server on MT2 at HQ through the vlan EOIP tunnel.
MT1 has NO dhcp servers configured; thus far I have not figured out how to get PC1 out through MT1 WAN...
I am guessing that I have to mark packets and re-route or maybe that dynamic configuration you speak of?
Probably a better way for what I am trying to accomplish; but I do not have the know..

Maybe missing something rudimentary here with my configuration...

MT1 has NO dhcp servers configured; thus far I have not figured out how to get PC1 out through MT1 WAN...

OK, so let's split the task into steps.

I may be obsessed with redundancy and resilience, hence for me the right thing to do is to use a local DHCP server at each site even though normally an L2 tunnel is established between them. For that approach, I've suggested you the bridge filter rules preventing DHCP requests from clients from passing through the tunnel to reach the "wrong" (remote) DHCP server. Of course, the address pools assigned to the two DHCP servers must not overlap.

But the local DHCP server at MT1 is not mandatory of course. If you don't mind that while the inter-site L2 tunnel is down, the PC1 will be unable to connect anywhere (including the internet) once its address lease expires, you can just reserve a static DHCP lease for PC1 on the MT2 (the easiest way is to let it get an address from the pool and then use /ip dhcp-server lease make-static), and bind a dedicated /ip dhcp-server network to it, which indicates MT1's address in the L2-tunneled subnet as the default gateway. Don't forget about the netmask parameter - if you don't state it explicitly, it will be taken from the address item, so /32 which is not good.

Once you get past this, the other steps (routes to non-connected internal subnets reachable via the tunnel) may need to be handled.

I am guessing that I have to mark packets and re-route or maybe that dynamic configuration you speak of?

By dynamic configuration I mean just DHCP, no need to be afraid of any additional complication.
If we gave the PC1 the IP address of MT2 as a default gateway and wanted to divert the packets to MT1, it would require to use /interface bridge filter and /interface bridge nat to substitute the MAC address of the MT2 by the one of MT1 when the PC would be sending ARP to MT2's gateway address. Believe me you'll lose much less hair if you stick with the DHCP method above. Besides, with the ARP NAT method, it would be impossible to use MT1 as a gateway to the internet and keep using MT2 as a gateway to the internal networks.

Hi sindy - in may case i need to transfer vlan10, is this corect set up for that?


/int vlan add name=br-vlan10 interface=br-vlan
/ip address add address=10.10.10.x interface=br-vlan10

L2TP=BCP
/interface l2tp-server server
set allow-fast-path=yes enabled=yes max-mru=1460 max-mtu=1460 mrru=1600

/ppp profile
add bridge=br-vlan change-tcp-mss=yes name=profile1-MT \
use-encryption=yes

im able to ping vl10 on other side wich is 10.10.10.x

is this correct?

Hi sindy - in may case i need to transfer vlan10, is this corect set up for that?

As it works the way you've set it up, it may mean two things:

• either that all VLANs are bridged across the tunnel because vlan-filtering on br-vlan is set to no,
• or that Mikrotik has changed the way how BCP tunnels are added as bridge ports.

If vlan-filtering=no, the broadcast traffic from the other VLANs wastes part of the available bandwidth of the tunnel. This was the motivation for the setup with an auxiliary bridge and an S-VLAN interface as proposed in the first half of post #4.

yeyee
vlan-filtering=no
but i'm not able to set up ethertype, because that one goes if i tick vlan-filtering=yes.
Definitely i'm trying to avoid EoIP because of overhead.

but i'm not able to set up ethertype, because that one goes if i tick vlan-filtering=yes.

Ah, it makes sense that ether-type is only relevant in association with vlan-filtering=yes. So my proposed setup may be simplified - the auxiliary bridge to which the BCP tunnel is added as a port may actually ignores ether-type, so you can even keep use-service-tag=no on the interface vlan used to add the outer tag as handling the frames as they flow from br-vlan to the auxiliary bridge. But it looks nicer if the outer tag is an S one and the inner one is a C one that if both are C ones

Thanks for the reply.

Once you get past this, the other steps (routes to non-connected internal subnets reachable via the tunnel) may need to be handled.

But the local DHCP server at MT1 is not mandatory of course. If you don't mind that while the inter-site L2 tunnel is down, the PC1 will be unable to connect anywhere (including the internet) once its address lease expires, you can just reserve a static DHCP lease for PC1 on the MT2 (the easiest way is to let it get an address from the pool and then use /ip dhcp-server lease make-static), and bind a dedicated /ip dhcp-server network to it, which indicates MT1's address in the L2-tunneled subnet as the default gateway. Don't forget about the netmask parameter - if you don't state it explicitly, it will be taken from the address item, so /32 which is not good.

Okay.. So I got this working without much difficulties. I added the MT1 router gateway as another DHCP network specific for PC1.. Then I had to add a route back to MT1 router gateway through the L3 connection on MT2.. At that point things were starting to work the way I was hoping. VLAN traffic stayed on vlan with MT2 and WAN traffic went some round about way 'I guess' back to MT1 via MT2 hard-coded DHCP network config. Then all the other internal subnets were unreachable (as explained they would be) so I had to add routes for them on MT1 using the vlan inteface.. then it all worked. And no, I never added a DHCP server to MT1 for this. Oh, and I did have to use bridge filtering on eoip-bridge..

So what could be done better here? Is there a better more seamless way..?
Not super thrilled about having to add static routes on MT2 to get this to work... and having to get to WAN by way of MT2 back to MT1.
I will logically conclude that it would be more efficient to go straight out MT1 to WAN from PC1 w/o involving MT2.. Maybe that bridge-filtering by mac...?

It seems that nobody likes the overhead of EOIP... so then '802.1ad service-vlan tagging to transport a trunk of 802.1Q customer-vlans' is the next best option?

Then I had to add route back to MT1 router gateway through the L3 connection on MT2.

I cannot see why this was necessary. Normally, PC1's address is from the subnet which is bridged across the link using the tunnel, so at MT2 side, the PC1 should be seen as just another machine on the LAN and no route should be required. Or maybe I've misunderstood what route you've actually added?

WAN traffic went some round about way 'I guess' back to MT1 via MT2 hard-coded DHCP network config.

The outgoing PC1 traffic itself doesn't go to MT2 and back - the DHCP network config tells PC1 to use MT1 as gateway straight away, that's the whole point.

Oh, and I did have to use bridge filtering on eoip-bridge..

Why?

It seems that nobody likes the overhead of EOIP... so then '802.1ad service-vlan tagging to transport a trunk of 802.1Q customer-vlans' is the next best option?

"nobody likes" - it's your decision after all, the point is that any tunnel adds some overhead, and EoIP over L3 L2TP is a "tunnel in tunnel". The L2 L2TP tunnel has the same amount of overhead as the L3 L2TP one, and you only have to pay those 4 bytes per frame, which is the 802.1ad tag, for the ability to bridge only those VLANs from the main bridge which you need. If you didn't need the L2TP and could use EoIP alone, it would be a different case.