/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=profilevpnYes, 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, are you refering to promiscuous mode (Vmware) or something else?
@Sindy, on what platform are your CHRs? Also Azure?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 portlist.
What does the log say?
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.Xok, but why if promiscuous mode is disabled would be of a problem ?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, are you refering to promiscuous mode (Vmware) or something else?
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.So what would actually cause a problem ?
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.Can I test this somehow? Do you maybe want to test?
@sindy,the virtual switch only accepts frames with source MAC address of the NIC itself.
@sindy,the virtual switch only accepts frames with source MAC address of theNICitself
Now it is understood, thanksYes. Sorry I wasn't precise enough.
Hm. Nothing weird there, BCP went up, and there is no complaint regarding inability to add the port to the bridge. OK, maybe it's really time to have a look directly there...I have enabled detailed logging and here is the log:
I really can not figure it out, it is beyond my level. If you are in the mood, I am very grateful. My email: anti spam editOK, maybe it's really time to have a look directly there...
No, I added the bridge interface on the l2tp profile on server CHR side (see OP) but didn't do the same on the client side as I tought that I don't need the bridge in the client because client in my config is client only for itself. That was wrong assumptionso you never added the bridge interface on the l2tp profile for both the client and server as it is already mentioned in the wiki...
Exactly, but you didn't do the same for the client... The wiki mentions that ...No, I added the bridge interface on the l2tp profile on server CHR side (see OP) but didn't do the same on the client side as I tought that I don't need the bridge in the client because client in my config is client only for itself. That was wrong assumptionso you never added the bridge interface on the l2tp profile for both the client and server as it is already mentioned in the wiki...
My assumption was wrong and I didn't know that both sides (server and client) have to have bridge. On my phisical routerboards I always needed bridges on both sides and offcourse everything worked. This time my l2tp client needed only to be bridged with chr server for itself so I didn't create bridge in the client and that was the problem