I have recently updated the Router OS on my microtik router. I have used openvpn bridge , Mikrotik being the server and I have used another openwrt based router for site-to-site bridging.
I have updated the Router OS from version 7.xxx to the latest version (7.14.2).
Here I have observed that I cannot ping hosts between the 2 sites. This worked before upgrading
What I hasve checked:
No configuration change was done on either side.
The openvpn bridge is created (the openvpn client succesfully connects) and there is Openvpn traffic
Under the “Ports” section, the openvpn interface is visible and is succesfully added to the bridge, together with all other etherx ports.
Under PPP → Active connections the openvpn client is shown as connected.
On the client side, everything is unchanged.
The client router’s address is 192.168.1.253, the main router’s address is 192.168.1.1.
I have tried pinging each other from both routers, doesn’t work. It was working previously before the update.
There is DHCP filtering on port 67-68 and no IP ranges are overlapping, each network has it’s delimited IP ranges setup in the DHCP server, but this should not matter, as also the routers don’t see each other.
Could you tell me what did change recently that could broke this ? It’s crucial for me that I have site-to-site bridging via openvpn and now it’s broken.
openvpn bridging broken in latest releases
Last edited by trex2000 on Sat Apr 06, 2024 10:08 pm, edited 1 time in total.
Re: openvpn bridging broken in latest releases
Something seems to be on the bridging side, if I open torch and leave it for a while on the openvpn interface, I see some traffic from hosts on the client side. So the openvpn client succesfully connects and communicates, however for some reason the packets do not reach the hosts on the LAN, that are part of the bridge.
Below are some screenshots of the setup.
Below are some screenshots of the setup.
Last edited by trex2000 on Sat Apr 06, 2024 10:09 pm, edited 2 times in total.
Re: openvpn bridging broken in latest releases
You do not have the required permissions to view the files attached to this post.
Re: openvpn bridging broken in latest releases
You do not have the required permissions to view the files attached to this post.
Re: openvpn bridging broken in latest releases
You do not have the required permissions to view the files attached to this post.
Re: openvpn bridging broken in latest releases
You do not have the required permissions to view the files attached to this post.
Re: openvpn bridging broken in latest releases
You do not have the required permissions to view the files attached to this post.
Re: openvpn bridging broken in latest releases
You do not have the required permissions to view the files attached to this post.
Re: openvpn bridging broken in latest releases
Here is the output from Mikrotik:
Here is the output from WRT based Openvpn client:
Code: Select all
18:08:59 ovpn,info connection established from 5.x.x.x, port: 59506 to 5.15.44.255
18:08:59 ovpn,debug,packet sent P_CONTROL_HARD_RESET_SERVER_V2 kid=0 sid=8ba8aecee454dec4 pid=0 DATA len=0
18:08:59 ovpn,debug,packet rcvd P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 sid=9ac07dc2ec111bdb pid=0 DATA len=0
18:08:59 ovpn,debug,packet sent P_ACK kid=0 sid=8ba8aecee454dec4 [0 sid=9ac07dc2ec111bdb] DATA len=0
18:08:59 ovpn,debug,packet rcvd P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 sid=9ac07dc2ec111bdb [0 sid=8ba8aecee454dec4] pid=0 DATA len=0
18:08:59 ovpn,debug,packet sent P_ACK kid=0 sid=8ba8aecee454dec4 [0 sid=9ac07dc2ec111bdb] DATA len=0
18:08:59 ovpn,debug,packet rcvd P_CONTROL kid=0 sid=9ac07dc2ec111bdb pid=1 DATA len=281
18:08:59 ovpn,debug,packet sent P_ACK kid=0 sid=8ba8aecee454dec4 [1 sid=9ac07dc2ec111bdb] DATA len=0
18:08:59 ovpn,debug,packet sent P_CONTROL kid=0 sid=8ba8aecee454dec4 pid=1 DATA len=1400
18:08:59 ovpn,debug,packet sent P_CONTROL kid=0 sid=8ba8aecee454dec4 pid=2 DATA len=752
18:08:59 ovpn,debug,packet rcvd P_ACK kid=0 sid=9ac07dc2ec111bdb [1 sid=8ba8aecee454dec4] DATA len=0
18:08:59 ovpn,debug,packet rcvd P_CONTROL kid=0 sid=9ac07dc2ec111bdb [2 sid=8ba8aecee454dec4] pid=2 DATA len=1174
18:08:59 ovpn,debug,packet sent P_ACK kid=0 sid=8ba8aecee454dec4 [2 sid=9ac07dc2ec111bdb] DATA len=0
18:08:59 ovpn,debug,packet rcvd P_CONTROL kid=0 sid=9ac07dc2ec111bdb pid=3 DATA len=911
18:08:59 ovpn,debug,packet sent P_ACK kid=0 sid=8ba8aecee454dec4 [3 sid=9ac07dc2ec111bdb] DATA len=0
18:08:59 ovpn,debug,packet sent P_CONTROL kid=0 sid=8ba8aecee454dec4 pid=3 DATA len=51
18:08:59 ovpn,debug,packet rcvd P_CONTROL kid=0 sid=9ac07dc2ec111bdb [3 sid=8ba8aecee454dec4] pid=4 DATA len=469
18:08:59 ovpn,debug,packet sent P_ACK kid=0 sid=8ba8aecee454dec4 [4 sid=9ac07dc2ec111bdb] DATA len=0
18:08:59 ovpn,info 5.15.177.161: using encoding - AES-128-CBC/SHA512
18:08:59 ovpn,debug peer info: IV_VER=2.5.8 IV_PLAT=linux IV_PROTO=6 IV_NCP=2 IV_CIPHERS=AES-256-GCM:AES-128-GCM:AES-128-CBC IV_LZ4=1 IV_LZ4v2=1 IV_LZO=1 IV_COMP_STUB=1 IV_COMP_STUBv2=1 IV_TCPNL=1
18:08:59 ovpn,info,account openvpn_otthon2 logged in, 10.8.0.252 from 5.x.x.x
18:08:59 ovpn,debug,packet sent P_CONTROL kid=0 sid=8ba8aecee454dec4 pid=4 DATA len=229
18:08:59 ovpn,debug,packet rcvd P_ACK kid=0 sid=9ac07dc2ec111bdb [4 sid=8ba8aecee454dec4] DATA len=0
18:08:59 ovpn,info <ovpn-openvpn_otthon2>: connected
18:09:00 ovpn,debug,packet rcvd P_CONTROL kid=0 sid=9ac07dc2ec111bdb pid=5 DATA len=42
18:09:00 ovpn,debug,packet sent P_ACK kid=0 sid=8ba8aecee454dec4 [5 sid=9ac07dc2ec111bdb] DATA len=0
18:09:00 ovpn,debug,packet sent P_CONTROL kid=0 sid=8ba8aecee454dec4 pid=5 DATA len=131
18:09:00 ovpn,debug,packet rcvd P_ACK kid=0 sid=9ac07dc2ec111bdb [5 sid=8ba8aecee454dec4] DATA len=0
Code: Select all
root@Otthon2:/etc/openvpn/config# /usr/sbin/openvpn --config /etc/openvpn/config/client.conf
2024-04-04 18:08:59 us=766256 DEPRECATED OPTION: --cipher set to 'AES-128-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-128-CBC' to --data-ciphers or change --cipher 'AES-128-CBC' to --data-ciphers-fallback 'AES-128-CBC' to silence this warning.
2024-04-04 18:08:59 us=778417 OpenVPN 2.5.8 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
2024-04-04 18:08:59 us=778649 library versions: OpenSSL 3.0.8 7 Feb 2023, LZO 2.10
2024-04-04 18:08:59 us=797719 WARNING: this configuration may cache passwords in memory – use the auth-nocache option to prevent this
2024-04-04 18:08:59 us=816906 Control Channel MTU parms [ L:1653 D:1212 EF:38 EB:0 ET:0 EL:3 ]
2024-04-04 18:08:59 us=944179 Data Channel MTU parms [ L:1653 D:1450 EF:121 EB:411 ET:32 EL:3 ]
2024-04-04 18:08:59 us=944552 Local Options String (VER=V4): 'V4,dev-type tap,link-mtu 1633,tun-mtu 1532,proto UDPv4,cipher AES-128-CBC,auth SHA512,keysize 128,key-method 2,tls-client'
2024-04-04 18:08:59 us=944672 Expected Remote Options String (VER=V4): 'V4,dev-type tap,link-mtu 1633,tun-mtu 1532,proto UDPv4,cipher AES-128-CBC,auth SHA512,keysize 128,key-method 2,tls-server'
2024-04-04 18:08:59 us=944885 TCP/UDP: Preserving recently used remote address: [AF_INET]5.x.x.x:1194
2024-04-04 18:08:59 us=945039 Socket Buffers: R=[180224->180224] S=[180224->180224]
2024-04-04 18:08:59 us=945152 UDP link local: (not bound)
2024-04-04 18:08:59 us=945266 UDP link remote: [AF_INET]5.x.x.x:1194
2024-04-04 18:08:59 us=945524 UDP WRITE [14] to [AF_INET]5.x.x.x:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
2024-04-04 18:08:59 us=948992 UDP READ [14] from [AF_INET]5.x.x.x:1194: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ ] pid=0 DATA len=0
2024-04-04 18:08:59 us=949175 TLS: Initial packet from [AF_INET]5.x.x.x:1194, sid=8ba8aece e454dec4
2024-04-04 18:08:59 us=949362 UDP WRITE [26] to [AF_INET]5.x.x.x:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ 0 ] pid=0 DATA len=0
2024-04-04 18:08:59 us=949822 UDP READ [22] from [AF_INET]5.x.x.x:1194: P_ACK_V1 kid=0 [ 0 ]
2024-04-04 18:08:59 us=950365 UDP WRITE [295] to [AF_INET]5.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=1 DATA len=281
2024-04-04 18:08:59 us=950916 UDP READ [22] from [AF_INET]5.x.x.x:1194: P_ACK_V1 kid=0 [ 0 ]
2024-04-04 18:08:59 us=953076 UDP READ [22] from [AF_INET]5.x.x.x:1194: P_ACK_V1 kid=0 [ 1 ]
2024-04-04 18:09:00 us=48019 UDP READ [1414] from [AF_INET]5.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=1 DATA len=1400
2024-04-04 18:09:00 us=48511 UDP WRITE [22] to [AF_INET]5.x.x.x:1194: P_ACK_V1 kid=0 [ 1 ]
2024-04-04 18:09:00 us=48821 UDP READ [766] from [AF_INET]5.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=2 DATA len=752
2024-04-04 18:09:00 us=54528 VERIFY OK: depth=1, CN=barney.ro
2024-04-04 18:09:00 us=55874 VERIFY KU OK
2024-04-04 18:09:00 us=56027 Validating certificate extended key usage
2024-04-04 18:09:00 us=56139 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2024-04-04 18:09:00 us=56246 VERIFY EKU OK
2024-04-04 18:09:00 us=56342 VERIFY OK: depth=0, CN=server.xxxxxxxx
2024-04-04 18:09:00 us=71660 UDP WRITE [1200] to [AF_INET]5.x.x.x:1194: P_CONTROL_V1 kid=0 [ 2 ] pid=2 DATA len=1174
2024-04-04 18:09:00 us=72160 UDP WRITE [925] to [AF_INET]5.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=3 DATA len=911
2024-04-04 18:09:00 us=74940 UDP READ [22] from [AF_INET]5.x.x.x:1194: P_ACK_V1 kid=0 [ 2 ]
2024-04-04 18:09:00 us=75896 UDP READ [22] from [AF_INET]5.x.x.x:1194: P_ACK_V1 kid=0 [ 3 ]
2024-04-04 18:09:00 us=82944 UDP READ [65] from [AF_INET]5.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=3 DATA len=51
2024-04-04 18:09:00 us=83778 UDP WRITE [495] to [AF_INET]5.x.x.x:1194: P_CONTROL_V1 kid=0 [ 3 ] pid=4 DATA len=469
2024-04-04 18:09:00 us=85899 UDP READ [22] from [AF_INET]5.x.x.x:1194: P_ACK_V1 kid=0 [ 4 ]
2024-04-04 18:09:00 us=90974 UDP READ [243] from [AF_INET]5.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=4 DATA len=229
2024-04-04 18:09:00 us=91612 UDP WRITE [22] to [AF_INET]5.x.x.x:1194: P_ACK_V1 kid=0 [ 4 ]
2024-04-04 18:09:00 us=91842 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
2024-04-04 18:09:00 us=92012 [server.xxxxxxx] Peer Connection Initiated with [AF_INET]5.x.x.x:1194
2024-04-04 18:09:00 us=95883 UDP READ [148] from [AF_INET]5.x.x.x:1194: P_DATA_V2 kid=0 DATA len=147
2024-04-04 18:09:00 us=96023 Key [AF_INET]5.x.x.x:1194 [0] not initialized (yet), dropping packet.
2024-04-04 18:09:00 us=119810 UDP READ [212] from [AF_INET]5.x.x.x:1194: P_DATA_V2 kid=0 DATA len=211
2024-04-04 18:09:00 us=119958 Key [AF_INET]5.x.x.x:1194 [0] not initialized (yet), dropping packet.
2024-04-04 18:09:01 us=187036 SENT CONTROL [server.xxxxxxx]: 'PUSH_REQUEST' (status=1)
2024-04-04 18:09:01 us=187525 UDP WRITE [56] to [AF_INET]5.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=5 DATA len=42
2024-04-04 18:09:01 us=189954 UDP READ [22] from [AF_INET]5.x.x.x:1194: P_ACK_V1 kid=0 [ 5 ]
2024-04-04 18:09:01 us=190421 UDP READ [145] from [AF_INET]5.x.x.x:1194: P_CONTROL_V1 kid=0 [ ] pid=5 DATA len=131
2024-04-04 18:09:01 us=190881 PUSH: Received control message: 'PUSH_REPLY,ping 20,ping-restart 60,route-gateway 10.8.0.1,ifconfig 10.8.0.252 255.255.255.0,peer-id 8'
2024-04-04 18:09:01 us=191329 OPTIONS IMPORT: timers and/or timeouts modified
2024-04-04 18:09:01 us=191511 OPTIONS IMPORT: --ifconfig/up options modified
2024-04-04 18:09:01 us=191682 OPTIONS IMPORT: route-related options modified
2024-04-04 18:09:01 us=191847 OPTIONS IMPORT: peer-id set
2024-04-04 18:09:01 us=192001 OPTIONS IMPORT: adjusting link_mtu to 1656
2024-04-04 18:09:01 us=192184 Using peer cipher 'AES-128-CBC'
2024-04-04 18:09:01 us=193638 Outgoing Data Channel: Cipher 'AES-128-CBC' initialized with 128 bit key
2024-04-04 18:09:01 us=193958 Outgoing Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication
2024-04-04 18:09:01 us=194196 Incoming Data Channel: Cipher 'AES-128-CBC' initialized with 128 bit key
2024-04-04 18:09:01 us=194465 Incoming Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication
2024-04-04 18:09:01 us=196923 TUN/TAP device tap11 opened
2024-04-04 18:09:01 us=197160 do_ifconfig, ipv4=1, ipv6=0
2024-04-04 18:09:01 us=197407 net_iface_mtu_set: mtu 1500 for tap11
2024-04-04 18:09:01 us=197737 sitnl_send: checking for received messages
2024-04-04 18:09:01 us=197945 sitnl_send: rtnl: received 36 bytes
2024-04-04 18:09:01 us=198214 net_iface_up: set tap11 up
2024-04-04 18:09:01 us=198496 sitnl_send: checking for received messages
2024-04-04 18:09:01 us=198689 sitnl_send: rtnl: received 36 bytes
2024-04-04 18:09:01 us=198903 net_addr_v4_add: 10.8.0.252/24 dev tap11
2024-04-04 18:09:01 us=199660 sitnl_send: checking for received messages
2024-04-04 18:09:01 us=199882 sitnl_send: rtnl: received 36 bytes
2024-04-04 18:09:01 us=200245 Initialization Sequence Completed
2024-04-04 18:09:01 us=200511 UDP WRITE [22] to [AF_INET]5.x.x.x:1194: P_ACK_V1 kid=0 [ 5 ]
2024-04-04 18:09:01 us=207227 UDP WRITE [132] to [AF_INET]5.x.x.x:1194: P_DATA_V2 kid=0 DATA len=131
Re: openvpn bridging broken in latest releases
I have tried to downgrade the Mikortik OS, but gives some missing package errors, even if the packages are uploaded to "Files".
But I would really like to solve the issue instead of downgrading.
But I would really like to solve the issue instead of downgrading.
Re: openvpn bridging broken in latest releases
I have managed to downgrade to 7.9.2 and now Openvpn bridge works without any other change.
So in newer versions something is broken.
I have opened a ticket at Mikrotik support, maybe somebody from there can figure out what is broken in the newer releases.
So in newer versions something is broken.
I have opened a ticket at Mikrotik support, maybe somebody from there can figure out what is broken in the newer releases.
Re: openvpn bridging broken in latest releases
Just wanted to say I experience the same issue.
I was able to downgrade to 7.12.1 and it solved the issue.
I guess the issue is related to new ovpn features in 7.14 (https://mikrotik.com/download/changelog ... able-v7_14), most notably the ability to add a route push.
I was able to downgrade to 7.12.1 and it solved the issue.
I guess the issue is related to new ovpn features in 7.14 (https://mikrotik.com/download/changelog ... able-v7_14), most notably the ability to add a route push.
Re: openvpn bridging broken in latest releases
Hello.
I can confirm, on 7.12 it is also working.
So it was broken most probably with the changes from 7.14
I will add this info to the ticket at mikrotik support.
I can confirm, on 7.12 it is also working.
So it was broken most probably with the changes from 7.14
I will add this info to the ticket at mikrotik support.
Re: openvpn bridging broken in latest releases
Hi,
@trex2000: I relaised exactly the same when I upgraded from 7.5 to 7.14.2. I tested on multiple devices. Developers, please fix it!
@velonet: Yes, the push route feature is new but seems to be useful. So hopefully developers don't have to remove it to fix the problem described.
Additionally: For bridged network connections, generally the bridge can have IP address and not the bridged interfaces. So you don't have to specify any local IP address in the profile for this kind of OpenVPN connection. There was a bug in older RouterOSs which made this field mandatory. (As a workaround, I put a fake IP address there and wrote a small script which removed the dynamic fake IP among IP addresses after bringing up the connection.) Now it seems this bug is fixed and the local IP address is not mandatory anymore for PPP profiles with bridged connection. I don't know exact version numbers but I suppose they fixed that somewhere between 7.5 and 7.14.2.
Regards,
Balázs
@trex2000: I relaised exactly the same when I upgraded from 7.5 to 7.14.2. I tested on multiple devices. Developers, please fix it!
@velonet: Yes, the push route feature is new but seems to be useful. So hopefully developers don't have to remove it to fix the problem described.
Additionally: For bridged network connections, generally the bridge can have IP address and not the bridged interfaces. So you don't have to specify any local IP address in the profile for this kind of OpenVPN connection. There was a bug in older RouterOSs which made this field mandatory. (As a workaround, I put a fake IP address there and wrote a small script which removed the dynamic fake IP among IP addresses after bringing up the connection.) Now it seems this bug is fixed and the local IP address is not mandatory anymore for PPP profiles with bridged connection. I don't know exact version numbers but I suppose they fixed that somewhere between 7.5 and 7.14.2.
Regards,
Balázs
Re: openvpn bridging broken in latest releases
Balazs, thanks for the hint. I was not aware that they solved it already so we don't need an IP adress. For bridging it's indeed not needed.
Let's hope they fix this soon. Until now I got no answer from the Mikrotik support team.
Let's hope they fix this soon. Until now I got no answer from the Mikrotik support team.
Re: openvpn bridging broken in latest releases
Is there anyone else who uses openvpn bridging and can confirm this issue ? Unfortunately the support team cannot reproduce the issue, and I am afraid this will end up broken forever and i will get stuck with an old version of RouterOS 
Re: openvpn bridging broken in latest releases
I have the same exact problem.
2 bridge clients connected (1 RV teltonika linux appliance and 1 macbook connected with viscosity).
when the tap interface go up I correctly receive ad in from selecteed lan pool but no traffic at all.
looking at arp records we can see all remote arp in incomplete state.
Tried with 7.14.2 and 15 beta 9 same issue, downgraded to 7.12.1 solved the problem.
N.
2 bridge clients connected (1 RV teltonika linux appliance and 1 macbook connected with viscosity).
when the tap interface go up I correctly receive ad in from selecteed lan pool but no traffic at all.
looking at arp records we can see all remote arp in incomplete state.
Tried with 7.14.2 and 15 beta 9 same issue, downgraded to 7.12.1 solved the problem.
N.
Re: openvpn bridging broken in latest releases
@konradnh: Thanks! I confirm that switching off Spanning Tree on the bridge of OpenVPN connection can be a workaround with RouterOS 7.14.x. However, I don't understand the dependency. STP's default setting was also RSTP in earlier RouterOSes and that was not a problem for OpenVPN bridged connections, so I think, it's just a workaround and not the solution. Developers should fix it.Looks familiar viewtopic.php?t=205097&start=300#p1064790
@trex2000: Please try this!
Re: openvpn bridging broken in latest releases
Read next messages in that thread and you will found answer. And if you can, please send supout ticket to support. My devices are in remote location and this is not convinient for me.
Re: openvpn bridging broken in latest releases
So the workaround is to remove the spanning tree protocol from lan bridge interface on microtik side? Tap interface in my case is bridged with a lan multiport bridge.
This is my Bridge Inteface attached
This is my Bridge Inteface attached
You do not have the required permissions to view the files attached to this post.
Re: openvpn bridging broken in latest releases
It seems RouterOS 7.14.3 fixes the problem more-or-less.
For dynamically bridged interfaces (including OpenVPN TAP connections) RouterOS adds them to the bridge with edge=auto parameter. In 7.14.2 it was edge=no. I turned back RSTP on the bridge and realized the connection still works. It also works with legacy STP, but needs about 40-50 seconds to initialize after establishing OpenVPN connection.What's new in 7.14.3 (2024-Apr-17 15:47):
[...]
*) bridge - use default "edge=auto" for dynamically bridged interfaces (PPP, VPLS, WDS);
[...]
Last edited by pellerb on Fri Apr 19, 2024 5:30 pm, edited 1 time in total.
Re: openvpn bridging broken in latest releases
Hi, pellerb,
It should still function even if STP is enabled, but remember that STP operates much slower than RSTP. Wait for at least a minute and observe if there's any noticeable change.
It should still function even if STP is enabled, but remember that STP operates much slower than RSTP. Wait for at least a minute and observe if there's any noticeable change.