VLAN trunk - master-slave way of config on physical interfaces

RouterOS General
1

Hi,

First my question, then my environment.

What is the best way to define these VLAN trunks and access point? What is the most flexible way? I will have a new switch what I want to add with the same VLANs but a new trunk cable. I’m not sure I did my configuration the best/easiest way.

So about my environment.

I have two Mikrotik device with Router OS:

  1. Mikrotik 951G-2HnD what I use as a WiFi access point
  2. Mikrotik CCR1009-7G-1C-1S+PC what is my core switch

There is a 3rd device as well, what is a TP-Link TL-SG1024DE smart switch.

I have two VLANs on top of these devices:

  • VLAN ID 2 for internal network
  • VLAN ID 3 for guest network

There is a VLAN trunk cable with the two VLANs between my WiFi AP and my core router.
There is another same VLAN trunk between my TP-Link switch and my core router.

Until now now, on my core switch (CCR1009), I just simply created two VLAN network interface per physical interface I want to use as a trunk.

There was the ‘master-slave’ interface configuration option before a RouterOS update months ago. Now it is already retired but it gave me an idea.

I though that I can create a bridge with ‘none’ protocol and use it as a ‘master’ interface for that two physical one I want to use as trunk with same configurations. When I made this now configuration for the VLANs, I experienced connectivity issues: wireless devices could reach wired once and vica versa but the internet. When I disabled one trunk physical interface inside the bridge, remained one could reach internet. What happened here?

I guess I did something wrong but then how I can create these kind of VLANs and then define firewall rules on the core router between them without creating separated VLAN interfaces for all the VLAN IDs per psychical trunk? I have seen bridge/VLAN to define tagged and access ports but it’s unclear how I can define firewall rules for them then.

Thanks for reading and for your advice in advance!

2

Suggest reading this source if your keen to do the vlan router method…
http://forum.mikrotik.com/t/using-routeros-to-vlan-your-network/126489/1

3

Thanks for the link! It has an example with proper comments what seems very useful. I tried to do my setup in a very similar way but based on this one I will try it again and come back.

Thanks & br,
Halacs

4

Thank you so much for the link! It helped a lot! Very good tutorial!

5

Yup pcunite is golden!

6

One more maybe a bit more advanced question:

I have site-to-site VPN between two mikrotik router. I have a same VLAN config on them with same IDs.

With my previous VLAN settings when I had separated bridges for all VLANs, I could set a bridge in the PPP profile to create a layer 2 VPN connection. Now, with this new VLAN configuration version, L2 VPN doesn’t work.

Can I configure it at all without Ethernet Over IP tunneling protocol?

I thought if I set bridge (bridge where I defined VLANs) in the PPP profile, L2TP VPN connection will forward VLAN tagged packages to the bridge at the other end of the VPN. It seems it’s not true somehow.

7

It never came to my mind to try to push VLANs through a L2TP tunnel in bridge mode, but I’ve expected it would be enough to configure the /interface bridge port and /interface bridge vlan items also for the L2TP interfaces. However, it seems RouterOS is not ready for this (at least as of 6.44.3). Whereas it adds the L2TP interfaces dynamically to the /interface bridge port list, albeit under the .id instead of the name, even after adding it (also using the .id) to /interface bridge vlan, the frames don’t get through if vlan-filtering=yes on the bridges - even the tagless ones don’t. If vlan-filtering=no, both tagless and tagged frames do get tunneled, but that doesn’t help you much.

So if you really need to tunnel L2 to another site via L3 network, use IPsec-encrypted EoIP rather than IPsec-encrypted L2TP with bridge mode activated.

8

Okay, thanks!

I the meanwhile, I managed EoIP on top of L2TP, but then it is secure enough if I set IPsec secret at the tunnel config. I hope I can set domain name for the remote host instead of the IP, but this is what I will check only tomorrow. WAN side firewall will be interesting, what I have to open for EoIP.

Well, my reason might be strange :slight_smile: I’m a dual-homed guy, meaning that I have a family house in the countryside and a flat in Budapest. Among others reasons, my DLNA server is in my house what I want to use from my other home and DLNA love to use broadcast messages. Of course, these things can be useful in the office too in my case.

9

You can and it even auto-updates the IP number if it changes dynamically.


Actually nothing in addition to what you’ve already open to permit IPsec. EoIP is a special use of GRE, and as GRE has no notion of ports, the connection tracker only uses source and destination IP addresses as connection ID. And as both ends actively send the GRE packets and the default firewall permits everything that is sent by the router itself, the tracked connection establishes at each end by the first packet sent by that end and the received packets then match connection-state=established.

10

It works now, thanks! I have set the EoIP tunnel used by the public IPs of the routers and turned off the L2TP site-to-site VPN. It seems all fine with tagged L2 connection.
Local endpoint can be only an IP at the EoIP settings. My WAN IP assigned dynamically via DHCP. You meant that this IP will be updated automatically when WAN port got a new one, right?
Remote endpoint can be a DNS name too so it’s straightforward. Both have to be set because of the IPsec according to the manual.

11

Unfortunately not. What I had in mind was only that if your WAN address is a dynamically changing public one and you’re subscribed to one of the DDNS services (such as Mikrotik’s /ip cloud, you can use the domain name as the remote-address parameter of the /interface eoip, and RouterOS will track the changes and update the remote IP accordingly.

The local-address must be specified as an IP number, the reason is that the dynamically generated IPsec policy needs to match a single /32 address as the SA works in transport mode. So at this side, the handling of the dynamically changing WAN address is a little complicated:

  • create an /interface bridge with protocol-mode=none and no member ports
  • assign some /32 private IP address which doesn’t conflict with any local subnet to that bridge
  • insert an action=accept protocol=gre src-address=the.ip.mentioned.above rule into chain=srcnat of /ip firewall nat before the default action=masquerade out-interface-list=WAN … one
  • add an action=dst-nat in-interface-list=WAN protocol=udp dst-port=500,4500 to-addresses=the.ip.mentioned.above to chain=dstnat of /ip firewall nat
  • set the “IP mentioned above” as the local-address of the /initerface eoip

How this whole mess works:
The local-address of the dynamically generated IPsec peer and the src-address of the dynamically generated IPsec policy are inherited from the local-address of the /interface eoip which is the static private one you’ve chosen. Due to this, the IPsec stack detects NAT so it encapsulates the ESP packets into UDP (which costs you some MTU). The EoIP transport packets are sent from the “IP mentioned above”, matched by the dynamically generated IPsec policy and encapsulated into the ESPinUDP transport packets which are also sent from the “IP mentioned above” but as they leave the machine, they are src-nated to its WAN IP. Because the IPsec policy uses “transport mode”, the “IP mentioned above” is not packed into the ESP, so when the EoIP packets get decrypted and decapsulated from it at the remote end, they seem to come from the WAN IP of the sender.
The dst-nat is there because one of the machines always sends the initial packet first, and without this rule in place, it would end on the WAN IP on the remote end where the necessary IPsec peer doesn’t listen.

Instead, you could configure the IPsec peer and policy manually, leaving peer’s local-address empty, and using tunnel=yes on the policy. This way you would avoid the NAT of the IPsec transport packets, so the ESP packets would not be encapsulated into UDP ones, but one more IP header would be used instead, so the “IP mentioned above” would have to be non-conflicting at both ends of the connection and used also as remote-address of the /interface eoip. Besides saving a few bytes of MTU, the advantage of this approach is that you can configure other IPsec settings freely, so you can use IKEv2 with certificate-based authentication etc.

Yet another approach is to use the script in dhcp client configuration to update the local-address of the /interface eoip at each WAN IP change, but I simply hate to wear the flash chip by rewriting configuration every now and then.

12

Sounds interesting! It’s a bit much for the first glance now so give me some time to process what you wrote then I’ll be back with the outcome.

13

Hi,

today I had some time to understand a bit more the configuration you suggested but it still not working somehow.
When I set local IP as my real IP on the WAN interface (ppoe now actually) my EoIP is working but in case of the private IP hack, it’s not.
Here is my configuration hopefully without the sensitive part: https://gist.github.com/halacs/d7015ca4f179bc900e0d7a703ec32717
Can you check it please what is wrong?

Thanks!

14

Well, you’ve posted the configuration of only one end, and you haven’t shown the runtime state using /ip ipsec peer print, /ip ipsec remote-peers print, /ip ipsec policy print. So I can’t say which part of the setup fails.

Technical remark, it is better to post everything right here between [code] and [/code] tags than to link to other site.

15

You are right, sorry. Here are the both end of the tunnel.

Router A (where I have set NAT because of dynamic IP)
[admin@router.local.example.com] > /ip ipsec peer print
Flags: X - disabled, D - dynamic, R - responder
0 D ;;; eoip-tunnel-Zoldmali
name=“peer17” address=a.b.5.107/32 local-address=172.20.0.1 profile=default exchange-mode=main send-initial-contact=yes

1 R name=“peer1” passive=yes profile=profile_1 exchange-mode=main send-initial-contact=yes
[admin@router.local.example.com] > /ip ipsec remote-peers print
Flags: R - responder, N - natt-peer

ID STATE REMOTE-ADDRESS DYNAMIC-ADDRESS UPTIME

0 message-1-sent a.b.5.107
1 R message-2-sent a.b.5.107
[admin@router.local.example.com] > /ip ipsec policy print
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default
0 T * group=default src-address=::/0 dst-address=::/0 protocol=all proposal=default template=yes

1 DA ;;; eoip-tunnel-Zoldmali
src-address=172.20.0.1/32 src-port=any dst-address=a.b.5.107/32 dst-port=any protocol=gre action=encrypt level=require
ipsec-protocols=esp tunnel=no proposal=default ph2-count=1
[admin@router.local.example.com] >
Router B
[admin@zoldmali.intra.example.com] > /ip ipsec peer print
Flags: X - disabled, D - dynamic, R - responder
0 D ;;; eoip-tunnel-Ostoros
name=“peer8” address=x.y.200.185/32 local-address=a.b.5.107 profile=default exchange-mode=main send-initial-contact=yes
[admin@zoldmali.intra.example.com] > /ip ipsec remote-peers print
Flags: R - responder, N - natt-peer

ID STATE REMOTE-ADDRESS DYNAMIC-ADDRESS UPTIME

0 message-3-sent x.y.200.185
[admin@zoldmali.intra.example.com] > /ip ipsec policy print
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default
0 T * group=default src-address=::/0 dst-address=::/0 protocol=all proposal=default template=yes

1 DA ;;; eoip-tunnel-Ostoros
src-address=a.b.5.107/32 src-port=any dst-address=x.y.200.185/32 dst-port=any protocol=gre action=encrypt level=require ipsec-protocols=esp tunnel=no proposal=default ph2-count=1

16

Okay, I forgot one thing, the peers dynamically generated by the EoIP astro clock act as both initiators and responders, so the connection may get messed up by the firewall. So in addition to the action=masquerade rule in chain=srcnat, you have to add also an action=dst-nat in-interface-list=WAN protocol=udp dst-port=500,4500 to-addresses=172.20.0.1 rule to chain=dstnat of /ip firewall nat.

The point is that when a connection attempt comes from the remote peer sooner than the local peer sends its own one, the firewall’s connection tracker creates a connection with the local WAN IP as destination, and this tracked connection is constantly updated so it never expires. The peer doesn’t accept packets coming to the WAN IP because it is set to accept only those coming to its local-address. It’s strange, though, because you only have the two addresses at one peer, the other one should handle this normally. But start from here, let’s see whether it helps.

But I’ve understood from what you wrote earlier that both ends have dynamic public IP so both need to be configured the other one’s domain name, is that true?

17

@sindy,
Have you tried above with L2TP and bridging control protocol?

18

Am I missing something? To me,

and

are the same thing.

19

Yes, that’s true. Both end are with dynamic IP changed quite rarely. Initial state is a EoIP tunnel with manually configured local IP addresses at both ends. It work fine already, but the dstnat-ed version.
First I’m trying to configure the one end. When I change local ip (let’s call this endpoint as ‘endpoint A’) EOIP tunnel became broken and I cannot ping the other network segment.

Unfortunately you did not forget to mention that two rule. They are already there in the nat table.
[admin@router.intra.example.com] > /ip firewall nat print
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; EoIP DDNS
chain=srcnat action=accept protocol=gre log=no log-prefix=“”

1 ;;; default configuration
chain=srcnat action=masquerade out-interface-list=WAN log=no log-prefix=“”

2 I ;;; university VPN
;;; sstp-UNIV not ready
chain=srcnat action=masquerade out-interface=sstp-UNIV

3 ;;; EoIP DDNS
chain=dstnat action=dst-nat to-addresses=172.20.0.1 to-ports=500 protocol=udp in-interface-list=WAN log=no log-prefix=“”

4 ;;; EoIP DDNS
chain=dstnat action=dst-nat to-addresses=172.20.0.1 to-ports=4500 protocol=udp in-interface-list=WAN log=no log-prefix=“”

5 ;;; HTTP
chain=dstnat action=dst-nat to-addresses=192.168.0.6 to-ports=80 protocol=tcp in-interface-list=WAN dst-port=80 log=no log-prefix=“”

6 ;;; HTTPS
chain=dstnat action=dst-nat to-addresses=192.168.0.6 to-ports=443 protocol=tcp in-interface-list=WAN dst-port=443 log=no log-prefix=“”

7 ;;; SSH
chain=dstnat action=dst-nat to-addresses=192.168.0.6 to-ports=22 protocol=tcp in-interface-list=WAN dst-port=22 log=no log-prefix=“”

8 X ;;; SMTP
chain=dstnat action=dst-nat to-addresses=192.168.0.199 to-ports=25 protocol=tcp in-interface-list=WAN dst-port=25 log=no log-prefix=“”

9 ;;; torrent kliens
chain=dstnat action=dst-nat to-addresses=192.168.0.1 to-ports=60995-60999 protocol=tcp in-interface-list=WAN dst-port=60995 log=no log-prefix=“”

10 ;;; szerver torrent kliens
chain=dstnat action=dst-nat to-addresses=192.168.0.6 to-ports=51413 protocol=tcp in-interface-list=WAN dst-port=51413 log=no log-prefix=“”

11 ;;; Syncthing (Gabor1)
chain=dstnat action=dst-nat to-addresses=192.168.0.1 to-ports=22000 protocol=tcp in-interface-list=WAN dst-port=22000 log=no log-prefix=“”


admin@router.intra.example.com] > /ip ipsec peer print
Flags: X - disabled, D - dynamic, R - responder
0 D ;;; eoip-tunnel-Zoldmali
name=“peer21” address=x.x.5.107/32 local-address=172.20.0.1 profile=default exchange-mode=main send-initial-contact=yes

1 R name=“peer1” passive=yes profile=profile_1 exchange-mode=main send-initial-contact=yes

[admin@router.intra.example.com] > /ip ipsec remote-peers print
Flags: R - responder, N - natt-peer

ID STATE REMOTE-ADDRESS DYNAMIC-ADDRESS UPTIME

0 R message-2-sent x.x.5.107
1 message-1-sent x.x.5.107

20

Would you mind disabling the manually created peer so that it wouldn’t interfere? It’s strange, I do this NAT trick quite routinely and it works.