OSPF issues on 1.4 rolling

General questions
1

Hey everyone!

I finally decided to turn here for help after wasting two days with OSPF on 1.4 rolling.

My topology is as following:

RouterOS openvpn to VyOS 1.4-rolling-202107122017
I can ping both internal IP’s (172.30.6.1 and 172.30.6.2) on both devices.

And I’m having another VIF on vyos eth0.190 with address 192.168.190.1/24

To my understanding, bringing up OSPF with:

 ospf {
     area 192.168.190.0 {
         network 172.30.6.0/30
     }
     interface vtun10 {
         cost 50
         dead-interval 40
         hello-interval 10
         network point-to-point
         priority 1
         retransmit-interval 5
         transmit-delay 1
     }
     redistribute {
         connected {
             metric-type 2
         }
     }
 }

brings up the OSPF on that network. And it actually does! Router gets about 20 routes from OSPF network but the issue is, it does not advertise 192.168.190.0/24 to OSPF.

I’ve googled, tested, and it always gets the routes from OSPF but never distributes it’s own connected.
Tried different area name, tried authentication, route-maps and nothing helps. Always the same.

I have a couple of VYOS 1.1.8 installations along with couple RouterOS’s and OSPF works as it needs to. All of them using OpenVPN to form private network and then pushing OSPF in to VPN interfaces.

I’m only experiencing this with 1.3 and 1.4 rolling.

Can you guys maybe help me out as to if I’m doing something wrong, or is there a possible bug?

Best regards,
Klemen

2

The configuration of route-map “CONNECT” is missing, and you are using it in redistribution.
Can you share this config?

3

Apologies sir. Disregard that route-map. I just edited config file for clarity.

4

It’s a really minimal configuration. Bare stuff just to make it on the internet.

Here is a complete config output:

vyos@vyos-test# show interfaces
 ethernet eth0 {
     hw-id f0:4d:a2:0e:ba:e4
     vif 190 {
         address 192.168.190.1/24
     }
     vif 700 {
         address 84.255.xxx.xxx/28
     }
 }
vyos@vyos-test# show interfaces openvpn
 openvpn vtun10 {
     description "Site-to-Site VPN"
     local-address 172.30.6.2 {
     }
     local-host 84.255.xxx.xxx
     local-port 1196
     mode site-to-site
     openvpn-option "--verb 3 --log /var/log/openvpn-vtun10.log"
     protocol tcp-passive
     remote-address 172.30.6.1
     remote-port 1196
     tls {
         ca-cert-file /config/auth/rtlc001/ca.pem
         cert-file /config/auth/rtlc001/rtlc001.pem
         dh-file /config/auth/rtlc001/dh2048.pem
         key-file /config/auth/rtlc001/rtlc001.key
         role passive
     }
 }
vyos@vyos-test# show protocols
 ospf {
     area 192.168.190.0 {
         network 172.30.6.0/30
     }
     parameters {
         router-id 84.255.xxx.xxx
     }
     redistribute {
         connected {
             metric-type 2
         }
     }
 }
 static {
     route 0.0.0.0/0 {
         next-hop 84.255.xxx.xxx {
         }
     }
 }

sites are reachable between each other …

vyos@vyos-test# ping 172.30.6.1
PING 172.30.6.1 (172.30.6.1) 56(84) bytes of data.
64 bytes from 172.30.6.1: icmp_seq=1 ttl=64 time=1.64 ms
64 bytes from 172.30.6.1: icmp_seq=2 ttl=64 time=1.75 ms
^C
--- 172.30.6.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 1.635/1.694/1.753/0.059 ms
vyos@vyos-test# ping 172.30.6.2
PING 172.30.6.2 (172.30.6.2) 56(84) bytes of data.
64 bytes from 172.30.6.2: icmp_seq=1 ttl=64 time=0.053 ms
64 bytes from 172.30.6.2: icmp_seq=2 ttl=64 time=0.023 ms
^C
--- 172.30.6.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1035ms
rtt min/avg/max/mdev = 0.023/0.038/0.053/0.015 ms

also as said, vyos gets the routes from OSPF

default nhid 6 via 84.255.xxx.xxx dev eth0.700 proto static metric 20
10.20.0.0/16 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
10.40.1.0/24 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
10.40.1.1 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
84.255.xxx.xxx/28 dev eth0.700 proto kernel scope link src 84.255.xxx.xxx
172.30.1.1 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
172.30.1.2 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
172.30.3.1 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
172.30.3.2 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
172.30.4.0/30 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
172.30.5.1 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
172.30.5.2 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
172.30.6.1 dev vtun10 proto kernel scope link src 172.30.6.2
172.30.11.1 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
172.30.11.2 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
172.30.13.1 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
172.30.13.2 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
172.30.14.0/30 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
172.30.15.1 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
172.30.15.2 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
172.30.50.0/30 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
172.30.202.0/24 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
172.30.203.0/24 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
172.31.201.0/24 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
192.168.8.0/24 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
192.168.12.0/24 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
192.168.28.0/24 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
192.168.32.0/22 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
192.168.190.0/24 dev eth0.190 proto kernel scope link src 192.168.190.1
192.168.195.0/24 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
192.168.200.0/24 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
192.168.201.0/24 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
192.168.202.0/24 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
192.168.203.0/24 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
192.168.204.0/24 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
192.168.205.0/24 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink
192.168.210.0/24 nhid 58 via 172.30.6.1 dev vtun10 proto ospf metric 20 onlink

but on the opposite router 172.30.6.1 which is RouterOS I don’t see 192.168.190.0/24

[admin@rtvc01] > ip route print
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 A S  0.0.0.0/0                          91.209.18.1               1
 1 A S  10.20.0.0/16                       192.168.8.9               1
 2 ADo  10.40.1.0/24                       172.30.4.2              110
                                           172.30.3.2
 3 ADo  10.40.1.1/32                       172.30.4.2              110
 8 ADo  172.30.1.1/32                      172.30.1.2              110
 9 ADC  172.30.1.2/32      172.30.1.1      rttc01 VPN                0
10 ADo  172.30.3.1/32                      172.30.3.2              110
11 ADC  172.30.3.2/32      172.30.3.1      rtde01 VPN                0
12 ADC  172.30.4.0/30      172.30.4.1      rtde02 IPIP               0
13 ADo  172.30.5.1/32                      172.30.5.2              110
14 ADC  172.30.5.2/32      172.30.5.1      rtlc001 VPN               0
15 ADC  172.30.6.2/32      172.30.6.1      vyostest VPN              0
16 ADo  172.30.11.1/32                     172.30.1.2              110
17 ADo  172.30.11.2/32                     172.30.1.2              110
18 ADo  172.30.13.1/32                     172.30.3.2              110
19 ADo  172.30.13.2/32                     172.30.4.2              110
20 ADo  172.30.14.0/30                     172.30.4.2              110
21 ADo  172.30.15.1/32                     172.30.5.2              110
22 ADo  172.30.15.2/32                     172.30.5.2              110
23 ADo  172.30.50.0/30                     172.30.1.2              110
                                           172.30.5.2
24 ADo  172.30.202.0/24                    172.30.1.2              110
25 ADo  172.30.203.0/24                    172.30.5.2              110
26 ADo  172.31.201.0/24                    172.30.1.2              110
27 ADC  192.168.8.0/24     192.168.8.3     vlan8                     0
28 ADC  192.168.12.0/24    192.168.12.3    vlan12                    0
29 ADC  192.168.28.0/24    192.168.28.5    vlan28                    0
30 ADC  192.168.32.0/22    192.168.32.3    vlan32                    0
31 ADo  192.168.195.0/24                   172.30.1.2              110
32 ADo  192.168.200.0/24                   172.30.1.2              110
33 ADo  192.168.201.0/24                   172.30.1.2              110
34 ADo  192.168.202.0/24                   172.30.1.2              110
35 ADo  192.168.203.0/24                   172.30.5.2              110
36 ADo  192.168.204.0/24                   172.30.1.2              110
37 ADo  192.168.205.0/24                   172.30.1.2              110
38 ADo  192.168.210.0/24                   172.30.1.2              110

172.30.5.2 and 172.30.1.2 are vyos 1.1.8 and those ‘just’ work :slight_smile:

5

Hi

I think there is some concept wrong, first you don’t need redistribute the connected if you just want to advertise your own prefix , use :

set protocols ospf area x network x.x.x.x/24

Something important , if you set ‘metric-type 2’ it changes the default metric for your own prefix :

If two different routers advertised two links to the same external destination but with different metric type, metric type 1 is preferred. If type of a metric left undefined the router will consider these external links to have a default metric type 2.
6

I’ve been checking , if you use the command above ,should see something like this in your ospf database :

show ip route ospf
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup

O   20.20.20.20/32 [110/1] via 0.0.0.0, dum0 onlink, weight 1, 00:08:06
O   192.168.190.0/24 [110/1] is directly connected, eth2.190, weight 1, 00:03:04
7

So modified a config a little bit …

vyos@vyos-test# show protocols
 ospf {
     area 192.168.190.0 {
         network 172.30.6.0/30
         network 192.168.190.0/24
     }
     parameters {
         router-id 84.255.xxx.xxx
     }
 }
 static {
     route 0.0.0.0/0 {
         next-hop 84.255.xxx.xxx {
         }
     }
 }

on the 1.4 vyos I see this:

vyos@vyos-test# run sh ip r
rip    route
[edit]
vyos@vyos-test# run sh ip route ospf
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup

O>* 10.20.0.0/16 [110/20] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:13
O>* 10.40.1.0/24 [110/20] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:13
O>* 10.40.1.1/32 [110/20] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:13
O>* 172.30.1.1/32 [110/70] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:14
O>* 172.30.1.2/32 [110/20] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:14
O>* 172.30.3.1/32 [110/60] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:14
O>* 172.30.3.2/32 [110/20] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:14
O>* 172.30.4.0/30 [110/20] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:14
O>* 172.30.5.1/32 [110/70] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:14
O>* 172.30.5.2/32 [110/20] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:14
O>* 172.30.11.1/32 [110/30] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:14
O>* 172.30.11.2/32 [110/40] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:14
O>* 172.30.13.1/32 [110/50] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:14
O>* 172.30.13.2/32 [110/40] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:14
O>* 172.30.14.0/30 [110/30] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:14
O>* 172.30.15.1/32 [110/30] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:14
O>* 172.30.15.2/32 [110/40] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:14
O>* 172.30.50.0/30 [110/20] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:13
O>* 172.30.202.0/24 [110/20] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:13
O>* 172.30.203.0/24 [110/20] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:13
O>* 172.31.201.0/24 [110/20] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:13
O>* 192.168.8.0/24 [110/20] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:14
O>* 192.168.12.0/24 [110/20] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:13
O>* 192.168.28.0/24 [110/20] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:13
O>* 192.168.32.0/22 [110/20] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:13
O   192.168.190.0/24 [110/1] is directly connected, eth0.190, weight 1, 00:01:13
O>* 192.168.195.0/24 [110/20] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:13
O>* 192.168.200.0/24 [110/20] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:13
O>* 192.168.201.0/24 [110/20] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:13
O>* 192.168.202.0/24 [110/20] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:13
O>* 192.168.203.0/24 [110/20] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:13
O>* 192.168.204.0/24 [110/20] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:13
O>* 192.168.205.0/24 [110/20] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:13
O>* 192.168.210.0/24 [110/20] via 172.30.6.1, vtun10 onlink, weight 1, 00:07:13

But 192.168.190.0/24 is still not propagated in to OSPF network. I even tried the 1.1.8 as a neighbor … not working.

8

@klemenk Can you try to change (temporary) the interface type to “TAP” between 1.1.8-1.4?

set interfaces openvpn vtun10 device-type 'tap'
set interfaces openvpn vtun10 local-address 172.30.6.2 subnet-mask 255.255.255.252

Let me know if it works.

9

@klemenk Could you try this setting ? thanks

10

Dear all.

I apologize for a delay but there have been some other pressing matters that I had to deal with. So here goes:

1.4 rolling side config:

# show interfaces openvpn vtun20
 description "OpenVPN site-to-site towards vyos 1.1.8"
 device-type tap
 encryption {
     cipher aes128
 }
 hash sha512
 local-address 172.30.100.2 {
     subnet-mask 255.255.255.252
 }
 local-host 84.255.xxx.xxx
 local-port 5002
 mode site-to-site
 remote-address 172.30.100.1
 remote-host 89.212.xxx.xxx
 remote-port 5001
 shared-secret-key-file /config/auth/openvpn.key

# show protocols ospf
 area 192.168.190.0 {
     network 192.168.190.0/24
     network 172.30.100.0/30
 }
 parameters {
     router-id 84.255.xxx.xxx
 }

1.1.8 side config:

# show interfaces openvpn vtun20
 description "OpenVPN site-to-site towards vyos 1.4.x rolling"
 device-type tap
 encryption aes128
 hash sha512
 local-address 172.30.100.1 {
     subnet-mask 255.255.255.252
 }
 local-host 89.212.xxx.xxx
 local-port 5001
 mode site-to-site
 remote-address 172.30.100.2
 remote-host 84.255.xxx.xxx
 remote-port 5002
 shared-secret-key-file /config/auth/openvpn.key

# show protocols ospf
 area 192.168.200.0 {
     network 172.30.1.0/30
     network 172.30.11.0/30
     network 172.30.100.0/30
 }

tunnel is up which is confirmed by a ping. Unfortunately OSPF is not working.

routes seen on 1.4

# ip r
default nhid 8 via 84.255.252.81 dev eth0.700 proto static metric 20
84.255.252.80/28 dev eth0.700 proto kernel scope link src 84.255.252.94
172.30.100.0/30 dev vtun20 proto kernel scope link src 172.30.100.2
192.168.190.0/24 dev eth0.190 proto kernel scope link src 192.168.190.1

routes seen on 1.1.8

# ip r
default via 89.212.xxx.xxx dev eth0.800  proto zebra
10.20.0.0/16 via 172.30.11.1 dev vtun11  proto zebra  metric 20
10.40.1.0/24 via 172.30.11.1 dev vtun11  proto zebra  metric 20
10.40.1.1 via 172.30.11.1 dev vtun11  proto zebra  metric 20
89.212.xxx.xxx/30 dev eth0.800  proto kernel  scope link  src 89.212.xxx.xxx
93.103.xxx.xxx/28 dev eth0.800  proto kernel  scope link  src 93.103.xxx.xxx
93.103.xxx.xxx dev eth0.800  proto kernel  scope link  src 93.103.xxx.xxx
93.103.xxx.xxx dev eth0.800  proto kernel  scope link  src 93.103.xxx.xxx
93.103.xxx.xxx dev eth0.800  proto kernel  scope link  src 93.103.xxx.xxx
127.0.0.0/8 dev lo  proto kernel  scope link  src 127.0.0.1
172.30.1.1 dev vtun10  proto kernel  scope link  src 172.30.1.2
172.30.3.1 via 172.30.11.1 dev vtun11  proto zebra  metric 60
172.30.3.2 via 172.30.11.1 dev vtun11  proto zebra  metric 40
172.30.4.0/30 via 172.30.11.1 dev vtun11  proto zebra  metric 30
172.30.5.1 via 172.30.11.1 dev vtun11  proto zebra  metric 70
172.30.5.2 via 172.30.1.1 dev vtun10  proto zebra  metric 60
172.30.11.1 dev vtun11  proto kernel  scope link  src 172.30.11.2
172.30.13.1 via 172.30.11.1 dev vtun11  proto zebra  metric 50
172.30.13.2 via 172.30.11.1 dev vtun11  proto zebra  metric 20
172.30.14.0/30 via 172.30.11.1 dev vtun11  proto zebra  metric 20
172.30.15.1 via 172.30.11.1 dev vtun11  proto zebra  metric 30
172.30.15.2 via 172.30.11.1 dev vtun11  proto zebra  metric 20
172.30.50.0/30 dev tun50  proto kernel  scope link  src 172.30.50.1
172.30.100.0/30 dev vtun20  proto kernel  scope link  src 172.30.100.1
172.30.202.0/24 dev vtun0  proto kernel  scope link  src 172.30.202.1
172.30.203.0/24 via 172.30.11.1 dev vtun11  proto zebra  metric 20
172.31.201.0/24 dev vtun2  proto kernel  scope link  src 172.31.201.1
192.168.8.0/24 via 172.30.11.1 dev vtun11  proto zebra  metric 20
192.168.12.0/24 via 172.30.11.1 dev vtun11  proto zebra  metric 20
192.168.28.0/24 via 172.30.11.1 dev vtun11  proto zebra  metric 20
192.168.32.0/22 via 172.30.11.1 dev vtun11  proto zebra  metric 20
192.168.195.0/24 dev eth0.600  proto kernel  scope link  src 192.168.195.1
192.168.200.0/24 dev eth0.200  proto kernel  scope link  src 192.168.200.1
192.168.201.0/24 dev eth0.201  proto kernel  scope link  src 192.168.201.1
192.168.202.0/24 dev eth0.202  proto kernel  scope link  src 192.168.202.1
192.168.203.0/24 via 172.30.50.2 dev tun50  proto zebra
192.168.204.0/24 dev eth0.204  proto kernel  scope link  src 192.168.204.1
192.168.205.0/24 dev eth0.205  proto kernel  scope link  src 192.168.205.1
192.168.210.0/24 dev eth0.210  proto kernel  scope link  src 192.168.210.1

Note that 1.1.8 is actually working nice with another vyos 1.1.8 and mikrotik routers as seen above.

11

Hi ,

I’ve been checking and with the version 1.4 , I can learn the prefix through openvpn site-to-site (with another router with the same version). You can run these commands :

show ip ospf neighbor
show ip ospf database
12

You use different areas for same network:

1.4
 area 192.168.190.0

1.1.8
 area 192.168.200.0

1.1.8 config


set interfaces openvpn vtun20 device-type 'tap'
set interfaces openvpn vtun20 encryption 'aes128'
set interfaces openvpn vtun20 hash 'sha512'
set interfaces openvpn vtun20 local-address 172.30.100.1 subnet-mask '255.255.255.252'
set interfaces openvpn vtun20 local-host '203.0.113.1'
set interfaces openvpn vtun20 local-port '5001'
set interfaces openvpn vtun20 mode 'site-to-site'
set interfaces openvpn vtun20 remote-address '172.30.100.2'
set interfaces openvpn vtun20 remote-port '5002'
set interfaces openvpn vtun20 shared-secret-key-file '/config/auth/foo.key'
set protocols ospf area 192.168.200.0 network '172.30.100.0/30'

1.4 config

set interfaces dummy dum0 address '100.64.44.1/24'
set interfaces dummy dum0 address '100.64.45.1/24'
set interfaces dummy dum0 address '100.64.46.1/24'
set interfaces dummy dum0 address '100.64.47.1/24'
set interfaces openvpn vtun20 device-type 'tap'
set interfaces openvpn vtun20 encryption cipher 'aes128'
set interfaces openvpn vtun20 hash 'sha512'
set interfaces openvpn vtun20 local-address 172.30.100.2 subnet-mask '255.255.255.252'
set interfaces openvpn vtun20 local-host '203.0.113.2'
set interfaces openvpn vtun20 local-port '5002'
set interfaces openvpn vtun20 mode 'site-to-site'
set interfaces openvpn vtun20 remote-address '172.30.100.1'
set interfaces openvpn vtun20 remote-host '203.0.113.1'
set interfaces openvpn vtun20 remote-port '5001'
set interfaces openvpn vtun20 shared-secret-key-file '/config/auth/foo.key'
set protocols ospf area 192.168.200.0 network '172.30.100.0/30'
set protocols ospf redistribute connected metric-type '2'

1.1.8 check routes

vyos@1-1-8:~$ show ip route ospf 
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route

O>* 100.64.44.0/24 [110/20] via 172.30.100.2, vtun20, 00:06:51
O>* 100.64.45.0/24 [110/20] via 172.30.100.2, vtun20, 00:06:51
O>* 100.64.46.0/24 [110/20] via 172.30.100.2, vtun20, 00:06:51
O>* 100.64.47.0/24 [110/20] via 172.30.100.2, vtun20, 00:06:51
O   172.30.100.0/30 [110/10] is directly connected, vtun20, 00:19:54
O   203.0.113.0/30 [110/20] via 172.30.100.2, 00:06:51
13

After fixing up a mishap with areas (doing to many things at once at work) I get to see this on 1.1.8

# run show ip ospf neighbor

    Neighbor ID Pri State           Dead Time Address         Interface            RXmtL RqstL DBsmL
192.168.8.4       1 Full/DROther      39.526s 172.30.11.1     vtun11:172.30.11.2       0     0     0
192.168.8.3       1 Full/DROther      31.162s 172.30.1.1      vtun10:172.30.1.2        0     0     0
84.255.252.94     1 Init/DROther      36.884s 172.30.100.2    vtun20:172.30.100.1      0     0     0

But on 1.4 I get to see this:

# run show ip ospf neighbor

Neighbor ID     Pri State           Dead Time Address         Interface                        RXmtL RqstL DBsmL

I then went in to a logs a bit … and caught this on 1.4 …

Jul 22 08:18:11 vyos-test ospfd[917]: [EC 134217741] Packet 192.168.205.1 [Hello:RECV]: NetworkMask mismatch on vtun20:172.30.100.2 (configured prefix length is 30, but hello packet indicates 0).
14

Double re-check configuration from both sites.
Re-add vpn/ospf configuration or just reboot the routers. I sent you the example above, where all works fine between 1.4 and 1.1.8.

15

I’ve set up two test routers and for sure everything works. Not quite sure what is going on here …

Will set up external interface and try OSPF from test 1.4 rolling towards RouterOS just to double check.

16

So as long as both routers are on same network it works (192.168.203.0/24).

But the moment I move these two routers off local network and on the internet, it stops working and I’m back to square one.

Will check if it is related to VIF’s.