On CHR last long-term v6.47.10 I can not get L2TP interface to be placed as a bridge port upon connection.
In contrast, the same thing fully works on my phisical routerboards, e.g. RB951G, hap ac3, etc..
Is it normal behaviour specific for CHR or…?
Config is:
/interface bridge
add name=bridge1
/ppp profile
add bridge=bridge1 change-tcp-mss=yes local-address=10.10.10.1 name=profilevpn remote-address=pool1 use-upnp=no
/ppp secret
add name=user password=pass profile=profilevpn
Did you take a look here in case you miss something ?
https://wiki.mikrotik.com/wiki/Manual:BCP_bridging_(PPP_tunnel_bridging)
Thank you Zacharius for joining.
I have looked and can not find any discrepancies. This is the document that I have based on my config.
I also think that it should work, but as I am no expert I posted here as I was very confused why it does not work on CHR.
Same thing and config works on my phisical Mikrotiks while it doesn’t work on CHR.
Just a crazy idea, is it possible that the “switch” aspect that is not present in CHR plays a role here?
Is here anyone with CHR that could test this? Many tnx in advance.
For test, I tried to reset all settings to default and then only apply the config presentrd above in the first post and it still doesn’t work
How exactly do you check that the joining of the L2 tunnel to the bridge does not work? You’ve only shown the part of the configuration related to L2TP, but not the one related to other ports of the bridge. I’d suppose you want to use the CHR to provide an L2 tunnel to the remote site to some other virtual machines running on the same host like the CHR.
If my guess is correct, bear in mind that most virtualisation platforms prevent “MAC address spoofing” by default, so if you want to use a network interface of a VM as a port of a bridge, you have to explicitly permit MAC address spoofing in the settings of that virtual network interface, otherwise the virtual switch will drop frames with any source MAC addresses different from the CHR’s own one on that interface.
Dear Sindy, tnx on your comment!!
I checked this with directly looking into the bridge ports after the l2tp/ipsec tunnel was established. As nothing was there (the l2tp dynamic interface was not in the list of bridge ports) I concluded that it doesn’t work as expected, because on my nonvirtual routerboards the interface is “in the bridge” as soon as the tunnel is established.
My intention was only to bridge vpn tunnels on that CHR - that CHR is the middle point between two remote nonvirtual sites (one behind ISP NAT). The idea was NOT to bridge the ether interface of the CHR with l2tp interface, but thank you very much for educating me in this way - I didn’t know that issue on MAC address spoofing.
what virtualization engine do you use ?
@sindy, are you refering to promiscuous mode ( Vmware) or something else?
It is an MS Azure virtual machine.
Btw, If some of you gurus want, I can gladly provide you access to the machine.
OK. So my L2TP - BCP tunnel between two CHRs works just fine, except that one of the CHRs (the client one) runs 6.47.9 and the other one runs 6.48.1, so neither exactly matches your 6.47.10.
At both, I can see the L2TP interface as a dynamically added item in the /interface bridge port list.
What does the log say?
Yes, I do, but as it may be called otherwise on other virtualization platforms (it’s called MAC address spoofing in Microsoft’s Hyper-V), I was more verbose about the behaviour.
@Sindy, on what platform are your CHRs? Also Azure?
I have first downgraded to 6.47.9 and later upgraded to 6.48.1 but there is no difference regarding this issue. L2TP/ipsec tunnel is well established but it is not added to the bridge.
The log doesn’t show errors as I can see. It says:
aug/10 00:17:32 ipsec,info respond new phase 1 (Identity Protection): 10.0.0.6[500]<=>X.X.X.X[500]
aug/10 00:17:32 ipsec,info ISAKMP-SA established 10.0.0.6[4500]-X.X.X.X[4500] spi:7ff025d4e6a0409f:02e5f96egc857151
aug/10 00:17:34 l2tp,info first L2TP UDP packet received from X.X.X.X
aug/10 00:17:34 l2tp,ppp,info,account user logged in, 10.10.10.253 from X.X.X.X
I am wondering is it possible that there is a problem with Azure as a platform for CHR as it was first necessary to convert from VHDX file to VHD before uploafing the virtual HD to the Azure? Maybe this resulted with this issue. Although, on the other side, upgrades, downgrades work all ok so it doesn’t seem that the installation is somehow “corrupted” in any sense…
Mine run at Hyper-V on my laptop. I didn’t expect Microsoft to use yet another virtualization technology on Azure, but as you say you had to convert the image, I’m not sure any more.
In the meanwhile I have also tried with upgrading to latest testing 6.49beta as well as latest development 7.1beta version but there is no improvement.
I was particularly motivated by seeing in the changelog of 6.49beta the following change:
*) chr - fixed OS provisioning on Azure;
but unfortunately without luck in this case.
It seams like a problem specifically related to CHR in combination with Azure.
@sindy, after some googling info arround it seams that Azure is for sure based on Hyper-V but with multiple specificities that make it different.
At the moment, I do not have new ideas in what direction to go trying to solve this.
ok, but why if promiscuous mode is disabled would be of a problem ?
Promiscuous mode should be enabled on cases where we have lets say nested VMs.
The CHR is directly connected to the port group of the vSwitch, so all traffic will be forwarded accordingly and not get dropped.
So what would actually cause a problem ?
Without promiscuous mode, the virtual switch only accepts frames with source MAC address of the NIC itself. So if a frame with some other source MAC address arrives from the remote site and the CHR egresses it through its virtual NIC to the local virtual switch, the virtual switch will drop it. This explanation corresponds to the name “MAC address spoofing” used by Hyper-V, but the property is configured at the virtual NIC.
Or maybe it is the reverse direction, where the NIC doesn’t accept frames with other destination MAC address than its own one (plus multicast plus broadcast of course). This explanation better matches the name “promiscuous mode” used by VMware, but the property is configured at the port group of the vSwitch or at the vSwitch itself.
Same issue exists with VRRP, as VRRP uses its own range of MAC addresses.
Can I test this somehow? Do you maybe want to test?
Following your comments, I tried now to set admin MAC on the bridge1 interface the same one as the ether1 virtual nic, but unfortunately also without sucess.
I don’t think the two things are related. If you bridge together two BCP tunnels, the MAC address security policy of the underlying virtualization technology is irrelevant - the transport packets carrying the encapsulated L2 frames are IP ones so no unexpected MAC addresses exist in their L2 headers. So your primary issue is the fact that the L2 interface is either not created at all or not added as a dynamic member port of the bridge.
/system logging add topics=l2tp,ppp will show you debug info for the startup process of the L2TP session.
I’ve only mentioned the MAC address spoofing in my first response because you didn’t elaborate enough in the OP, and then I just responded to @Zacharias’ follow-up question.
Ohh, thank you for clarification.
L2TP interface in my case is created but it is not added to the bridge.
I have enabled detailed logging and here is the log:
12:35:13 ipsec,info respond new phase 1 (Identity Protection): 10.0.0.6[500]<=>X.X.X.X[500]
12:35:14 ipsec,info ISAKMP-SA established 10.0.0.6[4500]-X.X.X.X[4500] spi:80dd084821580363:2f61db10f183724d
12:35:17 l2tp,info first L2TP UDP packet received from X.X.X.X
12:35:17 l2tp,ppp,debug <X.X.X.X>: LCP lowerup
12:35:17 l2tp,ppp,debug <X.X.X.X>: LCP open
12:35:17 l2tp,ppp,debug,packet <X.X.X.X>: rcvd LCP ConfReq id=0x1c
12:35:17 l2tp,ppp,debug,packet <mru 1450>
12:35:17 l2tp,ppp,debug,packet <magic 0x585edc22>
12:35:17 l2tp,ppp,debug,packet <X.X.X.X>: sent LCP ConfReq id=0x1
12:35:17 l2tp,ppp,debug,packet <mru 1450>
12:35:17 l2tp,ppp,debug,packet <magic 0x3917e7c7>
12:35:17 l2tp,ppp,debug,packet
12:35:17 l2tp,ppp,debug,packet <X.X.X.X>: sent LCP ConfAck id=0x1c
12:35:17 l2tp,ppp,debug,packet <mru 1450>
12:35:17 l2tp,ppp,debug,packet <magic 0x585edc22>
12:35:18 l2tp,ppp,debug,packet <X.X.X.X>: rcvd LCP ConfAck id=0x1
12:35:18 l2tp,ppp,debug,packet <mru 1450>
12:35:18 l2tp,ppp,debug,packet <magic 0x3917e7c7>
12:35:18 l2tp,ppp,debug,packet
12:35:18 l2tp,ppp,debug <X.X.X.X>: LCP opened
12:35:18 l2tp,ppp,debug,packet <X.X.X.X>: sent CHAP Challenge id=0x1
12:35:18 l2tp,ppp,debug,packet
12:35:18 l2tp,ppp,debug,packet
12:35:18 l2tp,ppp,debug,packet <X.X.X.X>: rcvd CHAP Response id=0x1
12:35:18 l2tp,ppp,debug,packet
12:35:18 l2tp,ppp,debug,packet
12:35:18 l2tp,ppp,info,account user logged in, 10.10.10.254 from X.X.X.X
12:35:18 l2tp,ppp,debug,packet <X.X.X.X>: sent CHAP Success id=0x1
12:35:18 l2tp,ppp,debug,packet S=D9E193FBF05AF6288A531ACFB555A4A1816CF945
12:35:18 l2tp,ppp,info : authenticated
12:35:18 l2tp,ppp,debug <X.X.X.X>: IPCP lowerup
12:35:18 l2tp,ppp,debug <X.X.X.X>: IPCP open
12:35:18 l2tp,ppp,debug,packet <X.X.X.X>: sent IPCP ConfReq id=0x1
12:35:18 l2tp,ppp,debug,packet <addr 10.10.10.1>
12:35:18 l2tp,ppp,debug <X.X.X.X>: IPV6CP open
12:35:18 l2tp,ppp,debug <X.X.X.X>: MPLSCP lowerup
12:35:18 l2tp,ppp,debug <X.X.X.X>: MPLSCP open
12:35:18 l2tp,ppp,debug,packet <X.X.X.X>: sent MPLSCP ConfReq id=0x1
12:35:18 l2tp,ppp,debug <X.X.X.X>: BCP lowerup
12:35:18 l2tp,ppp,debug <X.X.X.X>: BCP open
12:35:18 l2tp,ppp,debug,packet <X.X.X.X>: sent BCP ConfReq id=0x1
12:35:18 l2tp,ppp,debug,packet <mac-support 1>
12:35:18 l2tp,ppp,debug,packet <802-tagged-frame 1>
12:35:18 l2tp,ppp,debug,packet
12:35:18 l2tp,ppp,debug <X.X.X.X>: CCP lowerup
12:35:18 l2tp,ppp,debug <X.X.X.X>: CCP open
12:35:18 l2tp,ppp,debug,packet <X.X.X.X>: rcvd IPCP ConfReq id=0x15
12:35:18 l2tp,ppp,debug,packet <addr 0.0.0.0>
12:35:18 l2tp,ppp,debug,packet <X.X.X.X>: sent IPCP ConfNak id=0x15
12:35:18 l2tp,ppp,debug,packet <addr 10.10.10.254>
12:35:18 l2tp,ppp,debug,packet <X.X.X.X>: rcvd LCP ProtRej id=0x1d
12:35:18 l2tp,ppp,debug,packet 80 31 01 01 00 0c 03 03 01 08 03 01 09 02
12:35:18 l2tp,ppp,debug,packet <X.X.X.X>: rcvd MPLSCP ConfReq id=0xb
12:35:18 l2tp,ppp,debug,packet <X.X.X.X>: sent MPLSCP ConfAck id=0xb
12:35:18 l2tp,ppp,debug,packet <X.X.X.X>: rcvd IPCP ConfAck id=0x1
12:35:18 l2tp,ppp,debug,packet <addr 10.10.10.1>
12:35:18 l2tp,ppp,debug,packet <X.X.X.X>: rcvd MPLSCP ConfAck id=0x1
12:35:18 l2tp,ppp,debug <X.X.X.X>: MPLSCP opened
12:35:18 l2tp,ppp,info : connected
12:35:18 l2tp,ppp,debug,packet <X.X.X.X>: rcvd IPCP ConfReq id=0x16
12:35:18 l2tp,ppp,debug,packet <addr 10.10.10.254>
12:35:18 l2tp,ppp,debug,packet <X.X.X.X>: sent IPCP ConfAck id=0x16
12:35:18 l2tp,ppp,debug,packet <addr 10.10.10.254>
12:35:18 l2tp,ppp,debug <X.X.X.X>: IPCP opened
the virtual switch only accepts frames with source MAC address of the NIC itself.
@sindy,
So you mean that if for example a VM wants to communicate with a physical host, outside the virtualization engine, that physical host will see the mac address of the VM or the mac address of the physical NIC of the virtualization engine ?
Regardless of promiscuous mode enabled or not…
An external host will see the MAC address of the sending NIC of the VM.
The virtual switch does not substitute MAC addresses, it just filters the traffic on them if promiscuous mode is disabled, and it does so only on the virtual ports. The physical NICs of the host that act as member ports of the virtual switch are always transparent for any MAC address.