Configuring untagged VLAN on port bridged to VPN

RouterOS General
1

Afternoon,
I am trying to tweak a setup that we’ve had running for somewhere like 5-10 years but have been banging head against the wall trying to get what I want to work, with no luck. Hopefully someone can point at what I’m doing wrong? Our documentation is a bit outdated as it was written back when we first set this system up and while the devices have been updated, the documentation hasn’t been as we hadn’t changed the configuration…

We have two sites, the main site has a RB2011, and the secondary site has a 750. Rather than mess with the running equpment while we’re all working remotely, I also have an RB941 at home which I have configured in the same way, and that is what I’m using for testing so that I can fix it when I lock myself out. All devices are running 6.45.9.

The satellite sites have home-grade ADSL connections, the Mikrotiks are there to perform an SSTP VPN tunnel between the device and the RB2011 in the primary site, and to bridge the local ports with the VPN interface back to the main site. This is a L2 tunnel, so it carries multiple VLANs so that we can have a WiFi AP plugged into it which tags the traffic from different SSIDs and passes that tagged traffic back over the VPN tunnel. This has worked fine for well over 5 years. On all devices, one interface is the connection to local network, one for backdoor management and the rest of the ports bridged together with the SSTP endpoint(s)

There is now a need to connect another device to a port on the Mikrotik which needs to be in a particular VLAN, but which is not capable of tagging its own packets. So the port on the Mikrotik needs to be an untagged member of the appropriate VLAN. I cannot get that to work

The existing devices have no VLANs defined (except for the management VLAN which we use for managing it remotely), so currently it presumably just passes tagged data through unchanged from the WiFi AP, which comes out at the other end.

I have attempted to follow various samples in the wiki - I’ve set PVID on the bridge port, added the VLAN to the bridge VLAN table and added the port as untagged but when I enable vlan-filtering, it stops passing all traffic, both on the native VLAN and on the defined VLANs (management + the one I’m trying to configure).

Unlike the sample in the Bridge_VLAN_Table page on the wiki, I can’t add the uplink interface as tagged for that VLAN as it’s a dynamic SSTP interface and is not a valid option. It appears by default to be a trunk however. I can’t imagine that I’d need to enable VLAN filtering on the primary site end of the connection as well? Presumably it would just operate as it currently does, receiving all VLANs over the SSTP tunnel?

Does anyone have any thoughts? Happy to provide whatever command output or diagrams if it helps make anything clearer?

There are probably better ways to do this nowadays anyway, and I will look at EoIP in due course, but for now while I don’t have easy access to the remote site, I want to just get it to work with as little reconfiguration as possible!

2

You are not very clear about the type of the SSTP tunnel. The L3 interface created using /interface sstp-client add cannot be bridged to anything because it is an L3 interface; the L2 interface of a BCP-controlled L2 tunnel can be only added to a bridge by setting the name of that bridge as the value of the bridge parameter of the /ppp profile row used for that SSTP session, but in this case, you cannot configure vlan-filtering=yes on that bridge (or, better to say, you can but there is no way to specify pvid on the dynamically added /interface bridge port rows, and tagged frames do not get through to these tunnels if vlan-filtering=yes - or at least it didn’t work when I tested it last time, somwehere around 6.45.3 or so).

3

Could you not just change to l2tp/IPSec and have an EoIP tunnel?
This is how I have setup mine in order to allow AirPrint to remote sites as it cannot be routed (well not easily without avachi)
I’ve got 3 vlans running through three sites like this and have no issues

4

Possibly - I was trying to get by with minimal changes to the existing setup while I’m working remotely - if I messed up the change, getting physical access to the client end would not be simple. But I will do some reading on this.

Thanks,
Steve.

5

Apologies on not being clear! Looking at the documentation, it’s dated 2012 which shows how long it’s been since we (mostly my now-departed colleague) got this up and running. My memory going back that far is very hazy so have been relying mostly on that documentation as I’ve not kept up with developments since it was working flawlessly!

I am confused now as I didn’t know there were different types of SSTP tunnel. It was created using /interface sstp-client add, but it is bound to a bridge via the ppp profile. It does pass tagged frames through the interfaces and over the tunnel (I tested this by connecting a switch into a physical port on the Mikrotik I’m testing here at home and not only could I talk to the switch over our management VLAN, but I could configure a port on that switch to be untagged in another VLAN and equipment plugged in behaved as it should). Surely I don’t want to set the PVID on the SSTP interface port though do I? Only on the physical port which I want to be natively in that VLAN untagged? Although as you note, enabling vlan filtering stops it passing tagged (or untagged) packets.

Does any of this make my config clearer?

[admin@client] /interface sstp-client print
Flags: X - disabled, R - running
 0  R name="sstp-out1" max-mtu=1500 max-mru=1500 mrru=disabled connect-to=aa.bb.cc.dd:443 http-proxy=0.0.0.0:443
      certificate=none verify-server-certificate=no verify-server-address-from-certificate=yes
      user="user" password="password" profile=Bridge keepalive-timeout=60
      add-default-route=no dial-on-demand=no authentication=mschap2 pfs=no tls-version=any

[admin@client] /interface bridge print
Flags: X - disabled, R - running
 0 R name="Network" mtu=1500 actual-mtu=1500 l2mtu=1598 arp=enabled arp-timeout=auto
     mac-address=00:0C:42:E6:FA:8C protocol-mode=rstp fast-forward=no igmp-snooping=no auto-mac=no
     admin-mac=00:0C:42:E6:FA:8C ageing-time=5m priority=0x8000 max-message-age=20s forward-delay=15s
     transmit-hold-count=6 vlan-filtering=no dhcp-snooping=no

[admin@client] /interface bridge port print
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload
 #     INTERFACE                  BRIDGE                 HW  PVID PRIORITY  PATH-COST INTERNAL-PATH-COST    HORIZON
 0 I H ether5-bridge              Keble_Network          yes    1     0x80         10                 10       none
 1   H ether3-bridge-slave        Keble_Network          yes    1     0x80         10                 10       none
 2 I H ether4-bridge-slave        Keble_Network          yes    1     0x80         10                 10       none
 3  D  sstp-out1                  Keble_Network                 1     0x80         10                 10       none

[admin@client] /interface print
Flags: D - dynamic, X - disabled, R - running, S - slave
 #     NAME                                TYPE       ACTUAL-MTU L2MTU  MAX-L2MTU MAC-ADDRESS
 0  R  ether1-gateway                      ether            1500  1600       4076 00:0C:42:E6:FA:88
 1     ether2-management                   ether            1500  1598       2028 00:0C:42:E6:FA:89
 2  RS ether3-bridge-slave                 ether            1500  1598       2028 00:0C:42:E6:FA:8A
 3   S ether4-bridge-slave                 ether            1500  1598       2028 00:0C:42:E6:FA:8B
 4   S ether5-bridge                       ether            1500  1598       2028 00:0C:42:E6:FA:8C
 5  R  Network                             bridge           1500  1598            00:0C:42:E6:FA:8C
 6  RS sstp-out1                           sstp-out         1500
 7  R  vlan-1000                           vlan             1500  1594            00:0C:42:E6:FA:8C

[admin@client] /ppp profile print
Flags: * - default
 0 * name="default" use-mpls=default use-compression=default use-encryption=default only-one=default
     change-tcp-mss=yes use-upnp=default address-list="" on-up="" on-down=""

 1   name="Bridge" bridge=Network use-mpls=default use-compression=default use-encryption=yes
     only-one=default change-tcp-mss=default use-upnp=default address-list="" on-up="" on-down=""
6

OK, this is a sufficient information, and I could have seen it in the OP had I read it more carefully.

As I’ve said earlier, and as you’ve discovered yourself, in this setup, the end of the L2 tunnel is made a member port of the bridge dynamically, and in that case, this port stops forwarding completely if you switch on vlan-filtering on the bridge. So you cannot restrict which VLANs will be forwarded through the tunnel at the server side, nor you can limit which VLANs will be permitted on the port at the client side, nor can you have a port with a specific PVID on the same bridge (as tagging and untagging on ingress and egress only works when vlan-filtering is set to yes).

So to add an access port to a VLAN which goes tagged through the BCP tunnel, you have to add another bridge on the client, and do it the old way: existing_bridge → (tagged)interface vlan X(untagged) → bridge_X → etherN:

/interface vlan
add interface=Network vlan-id=1234 name=Network.1234

/interface bridge
add name=bridge-vlan-1234

/interface bridge port
add bridge=bridge-vlan-1234 interface=Network.1234
add bridge=bridge-vlan-1234 interface=ether5

The problem of this setup is that the broadcast traffic of all VLANs is transported to the clients, which is probably not what you want on satellite links. Migration to EoIP will allow to activate vlan-filtering on the server side once all clients get migrated; the good news is that you can migrate the clients to EoIP one by one, as the EoIP tunnels can be made member ports of the same bridge like the BCP tunnels. The migration is pretty straightforward, you configure a static IP address to each client on its /ppp secret row, create an /interface eoip with this address as remote-address, and add a corresponding static row to /interface bridge port at both the client side and the server side. You just have to add another /ppp profile row which doesn’t have the bridge parameter set, and link the /ppp secret row of this client to this new profile, as otherwise you’d create an L2 loop.

All the above is based on the premise that you’ve got some very good reasons to use L2 tunneling at all, let alone on satellite links.

7

Many thanks, that got it sorted! Yes, I do VLAN pruning upstream of the unit at the main site anyway, so at least we minimise to only the VLANs we need at the remote site.

Now I’ve got that working as is, I will start to look at moving towards EoIP on my test device (and update our documentation!)

Thanks again,
Steve